Seite 1 von 2
TFTP image Timeout
Verfasst: 13 Okt 2015, 14:29
von bademeister
Hallo alle zusammen,
bei uns stehen standardmäßig alle Clients auf "Network Boot". Leider verzeichnen wir seit heute relativ lange Wartezeiten beim beziehen des Boot-Images.
Die Maschinen laufen los, erhalten eine IP und machen dann einen TFTP Aufruf. Dieser läuft nach 30s in den Timeout und der Rechner bootet von der lokalen Festplatte.
Ist ein netboot Produkt auf setup gestellt dauert es eine Zeit und das Produkt bootet. Man sieht zwar keinen unmittelbaren Fortschritt mehr, allerdings ist das in erster Linie nicht tragisch. Die Boot-Zeit von 30s hingegen schon.
Ich kann leider nicht rausfinden woran es liegt. Gibt es Ideen?
Viele Grüße,
Felix
NACHTRAG:
Nach einem Neustart des Servers läuft es wieder. Ein:
liefert aber z.B. keine Rückmeldung. Weiß noch nicht genau was da im Argen liegt. Vermutlich schmiert der opsi-atftpd irgendwann ab. Allerdings bin ich bei der Suche nach Gründen noch nicht weiter gekommen.
Re: TFTP image Timeout
Verfasst: 13 Okt 2015, 16:20
von wolfbardo
Falls Debian 8 verwendet wird, so bitte die release notes (known issues) lesen
Gruss
Bardo Wolf
Re: TFTP image Timeout
Verfasst: 13 Okt 2015, 17:29
von bademeister
Handelt sich um ein ubuntu 14.04. Von daher dürfte das keine Rolle spielen.
Re: TFTP image Timeout
Verfasst: 14 Okt 2015, 01:03
von m.radtke
Bitte prüfen ob in der Datei /etc/default/aftfpd die variable USE_INETD auf True steht. Wenn ja den netzdienst mit
neustarten
Re: TFTP image Timeout
Verfasst: 14 Okt 2015, 09:29
von bademeister
Moin moin,
jep. Das hilft soweit als Übergangslösung. Allerdings stürzt das gute Stück dennoch ab und an ab.
Ich habe aber ggf. in der Zwischenzeit einen Client identifiziert nach welchem das immer passiert. Ich werde das mal weiter untersuchen und melde mich.
Viele Grüße
Re: TFTP image Timeout
Verfasst: 15 Okt 2015, 10:43
von bademeister
Soo,
also nach Beobachten des Problems kann ich folgendes sagen:
- der TFTP Server wird über inetd nach unbestimmter Zeit nicht mehr gestartet (besondere Vorkommnisse sind leider keine aufgefallen)
- ein Neustart des inetd behebt das Problem kurzzeitig
Ich weiß nicht, ob es in einem Zusammenhang steht, jedoch spuckt der Server (ubuntu 14.04.3) seit dem apt-get upgrade auf 4.0.6 auch Fehlermeldungen im logrotate:
Code: Alles auswählen
/etc/cron.daily/logrotate:
error: unable to open /var/log/syslog.1 for compression
error: error renaming /var/log/upstart/console-setup.log.7.gz to /var/log/upstart/console-setup.log.8.gz: Keine Berechtigung
error: error renaming /var/log/upstart/container-detect.log.7.gz to /var/log/upstart/container-detect.log.8.gz: Keine Berechtigung
error: error renaming /var/log/upstart/kmod.log.7.gz to /var/log/upstart/kmod.log.8.gz: Keine Berechtigung
error: error renaming /var/log/upstart/mountall.log.7.gz to /var/log/upstart/mountall.log.8.gz: Keine Berechtigung
error: error renaming /var/log/upstart/mysql.log.7.gz to /var/log/upstart/mysql.log.8.gz: Keine Berechtigung
error: error renaming /var/log/upstart/procps-static-network-up.log.7.gz to /var/log/upstart/procps-static-network-up.log.8.gz: Keine Berechtigung
error: error renaming /var/log/upstart/procps-virtual-filesystems.log.7.gz to /var/log/upstart/procps-virtual-filesystems.log.8.gz: Keine Berechtigung
error: error renaming /var/log/upstart/rsyslog.log.7.gz to /var/log/upstart/rsyslog.log.8.gz: Keine Berechtigung
error: error renaming /var/log/upstart/systemd-logind.log.7.gz to /var/log/upstart/systemd-logind.log.8.gz: Keine Berechtigung
error: error renaming /var/log/upstart/ureadahead.log.7.gz to /var/log/upstart/ureadahead.log.8.gz: Keine Berechtigung
error: error renaming /var/log/upstart/ureadahead-other.log.7.gz to /var/log/upstart/ureadahead-other.log.8.gz: Keine Berechtigung
run-parts: /etc/cron.daily/logrotate exited with return code 1
Jetzt habe ich das natürlich in erster Linie in keinen Zusammenhang gesetzt und da wäre dieses Forum hier auch die falsche Baustelle. Nachdem es jedoch sicherlich einige Linux-Experten hier gibt, kann mir vielleicht jemand helfen, denn ich bin an den Grenzen meiner Kenntnis. An den Rechten liegt es nicht: der cronjob wird als root aufgerufen und die Berechtigungen der Logs liegen auf: root:syslog
Was erstaunlich ist, wir haben mehrere Server mit exakt gleichem Stand laufen (Aktualisierungen laufen zentral), welche sich lediglich in den installierten Diensten unterscheiden: webserver, svn, dhcp und eben einer davon opsi. Ich kann mir also nicht erklären wo der Fehler herkommt. Es ist auch nur eine wage Vermutung, ob der TFTP-Timeout in Zusammenhang mit den Problemen vom logrotate steht. Nachdem beides meist passiert wenn ich nicht im Büro bin (folglich nachts
) war das ein verzweifelter Erklärungsversuch.
Ich bin über jeden Input dankbar.
-- Felix
Re: TFTP image Timeout
Verfasst: 19 Okt 2015, 08:34
von bademeister
NACHTRAG:
Ich habe nun vor dem Wochenende mal den kompletten Ordner /var/log in /var/log.bak umbenannt und einen neuen leeren mit root:syslog angelegt.
Fazit: Erstmal keine Mails - was jedoch auf einen Fehler im Mailserver herausführte, da dieser seinen log nicht schreiben durfte.
Ein anschließendes: logrotate -f /etc/logrotate.conf führte erneut zu fehlenden Berechtigungen. Mit Debug habe ich raufgefunden, dass logrotate versucht den syslog mit der euid: 993 zu rotieren. Und ein nachschauen der id führte zu: 993:opsiconfd.
Folglich muss wohl ein Fehler in der logrotate-Konfiguration für die opsi-Tools vorliegen. Dort habe ich nun sämtliche Einträge auskommentiert, welche die Berechtigungen des Logs festlegen. Folglich:
/etc/logrotate.d/opsi-backup --> # su opsiconfd opsiadmin
/etc/logrotate.d/opsiconfd --> # su opsiconfd opsiadmin
/etc/logrotate.d/opsi-product-updater --> # su opsiconfd opsiadmin
/etc/logrotate.d/opsipxeconfd --> # su root opsiadmin
Ein erneutes logrotate -f lieferte keinerlei Fehler mehr und z.B. syslog wurde erfolgreich rotiert mit root-Rechten.
Ich vermute also, dass in den logrotate configs etwas geändert worden ist beim Update auf 4.0.6.
Meine finale Frage nun an uib: Habe ich mit meinem Auskommentieren irgendwelche Fehler in Zugriffen zu erwarten? Werden die Logs an anderer Stelle gebraucht und folglich die Zugriffsrechte benötigt?
Viele Grüße und einen schönen Start in die Woche,
Felix
EDIT: Ah.. das Thema mit dem TFTP Timeout hat sich damit leider nicht behoben. Beim Starten meines Rechners heute Früh trat der Fehler erneut auf und konnte nur durch ein service openbsd-inetd restart behoben werden.
Re: TFTP image Timeout
Verfasst: 23 Okt 2015, 13:06
von n.wenselowski
Hi,
wie in den Releasenotes geschrieben, wurde die Logrotate-Config geändert
Mehr dazu in
diesem Thread.
-N
Re: TFTP image Timeout
Verfasst: 23 Okt 2015, 14:08
von bademeister
Vielen Dank. Werde das mal umsetzen.
Notiz an mich: Beim nächsten Mal ReleaseNotes lesen: Telefon, Outlook etc. abstellen und konzentrieren!
Re: TFTP image Timeout
Verfasst: 10 Nov 2015, 10:13
von albrecht
Hallo zusammen,
könnten wir hier noch einmal auf das eigentliche Thema zurück kommen, denn wir haben das gleiche Problem mit unserem Opsi-server
Gestern haben wir alle aktuellen Updates eingespielt und nun stürzt ständig der atftp dienst ab, bzw. liefert nicht aus.
PS: Das Problem mit dem Syslog haben ich schon behoben.
Umgebung Linux 12.04
Clients und Server im gleichen Netz
Grüße aus dem Norden