E1: kernel-update

[Rolf Bensch]

Hallo!,

bei der Installation des OpenSSL-Sicherheitsupdate werde ich auf ein
Kernel-Update hingewiesen. Beim Versuch einer Update-Installation von
eisfair Kernel (Linux 3.2.77-eisfair-1 SMP):

Sorry, only installing on eisfair-1 systems with kernel
3.2.75-eisfair-1
or
3.2.77-eisfair-1!

Aktuell läuft: base: 2.7.2 eiskernel: 2.5.2 (3.2.54-eisfair-1-SMP).

Was sollte ich tun? "Kernel 3.2.77 source loader"?

tnx Rolf

[Marcus Roeckrath]

Hallo Rolf,

Installiere zunächst den aktuellen Kernel in der -Virt-Version.

Danach wieder den normalen aktuellen -smp.

Danach noch /va/install/packages/eiskernel-virt deinstallieren.

Und demnächst bitte am Ball bleiben.

--
Gruss Marcus

[Holger Behmann]

Hallo Marcus,

sorry for PM!

> Hallo Rolf,
>
> Rolf Bensch wrote:
>
>> bei der Installation des OpenSSL-Sicherheitsupdate werde ich auf ein
>> Kernel-Update hingewiesen. Beim Versuch einer Update-Installation von
>> eisfair Kernel (Linux 3.2.77-eisfair-1 SMP):
>>
>> Sorry, only installing on eisfair-1 systems with kernel
>> 3.2.75-eisfair-1
>> or
>> 3.2.77-eisfair-1!
>>
>> Aktuell läuft: base: 2.7.2 eiskernel: 2.5.2 (3.2.54-eisfair-1-SMP).
>>
>> Was sollte ich tun? "Kernel 3.2.77 source loader"?
>
> Installiere zunächst den aktuellen Kernel in der -Virt-Version.
>

Saving to: 'eiskernel-virt.tar.gz'

eiskernel-virt.tar.gz
100%[=====================================================================>]
25.40M 604KB/s in 44s

2016-05-12 00:42:17 (593 KB/s) - 'eiskernel-virt.tar.gz' saved
[26636204/26636204]

Please wait ...
Saving your kernel configuration in /tmp/kernel-backup.tar.gz:
/boot
/etc/lilo.conf
/lib/modules/2.4.31
/lib/modules/3.2.67-eisfair-1-SMP
/System.map-3.2.67-eisfair-1-SMP
/var/install/packages/eiskernel
/var/install/packages/eiskernel-smp
tar:
lib/modules/3.2.67-eisfair-1-SMP/kernel/drivers/block/paride/pcd.ko:
File shrank by 11384 bytes; padding with zeros


Error occured during taring your kernel configuration, cancelling
installation.
Kernel update failed.

Was soll mir diese Meldung sagen? Tar.gz kaputt?

> Danach wieder den normalen aktuellen -smp.
>

Würde ich gerne...

> Danach noch /va/install/packages/eiskernel-virt deinstallieren.
>
> Und demnächst bitte am Ball bleiben.
>

Gruß
Holger

[Thomas Bork]

Am 12.05.2016 um 00:49 schrieb Holger Behmann:

> Saving your kernel configuration in /tmp/kernel-backup.tar.gz:
> /boot
> /etc/lilo.conf
> /lib/modules/2.4.31
> /lib/modules/3.2.67-eisfair-1-SMP
> /System.map-3.2.67-eisfair-1-SMP
> /var/install/packages/eiskernel
> /var/install/packages/eiskernel-smp
> tar:
> lib/modules/3.2.67-eisfair-1-SMP/kernel/drivers/block/paride/pcd.ko:
> File shrank by 11384 bytes; padding with zeros
> Error occured during taring your kernel configuration, cancelling
> installation.
> Kernel update failed.
> Was soll mir diese Meldung sagen? Tar.gz kaputt?

Steht doch da:
Es ist tar nicht fehlerfrei gelungen, eine Sicherung des Systems
(speziell der Datei
lib/modules/3.2.67-eisfair-1-SMP/kernel/drivers/block/paride/pcd.ko)
anzulegen. Deshalb wird das Kernel-Update abgebrochen.

1.
Ist das ein virtuelles oder reales System?

2.
Was steht zum fraglichen Zeitpunkt in /var/log/messages?

Die tar-Meldung sagt aus, dass die Datei 11384 Bytes kleiner ist, als
sie behauptet zu sein. tar füllt die Differenz deshalb mit Nullen auf.
Das ergibt einen Exit-Code, der nicht 0 ist und das sagt mir, dass die
Sicherung nicht korrekt gelaufen ist und ich breche ab.

--
der tom
[eisfair-team]

[Marcus Roeckrath]

Hallo Holger,

Holger Behmann wrote:

>> Installiere zunächst den aktuellen Kernel in der -Virt-Version.
>>
> Saving to: 'eiskernel-virt.tar.gz'
>
> eiskernel-virt.tar.gz
>
100%[=====================================================================>]
> 25.40M 604KB/s in 44s
>
> 2016-05-12 00:42:17 (593 KB/s) - 'eiskernel-virt.tar.gz' saved
> [26636204/26636204]
>
> Please wait ...
> Saving your kernel configuration in /tmp/kernel-backup.tar.gz:
> /boot
> /etc/lilo.conf
> /lib/modules/2.4.31
> /lib/modules/3.2.67-eisfair-1-SMP
> /System.map-3.2.67-eisfair-1-SMP
> /var/install/packages/eiskernel
> /var/install/packages/eiskernel-smp
> tar:
> lib/modules/3.2.67-eisfair-1-SMP/kernel/drivers/block/paride/pcd.ko:
> File shrank by 11384 bytes; padding with zeros
>
>
> Error occured during taring your kernel configuration, cancelling
> installation.
> Kernel update failed.
>
> Was soll mir diese Meldung sagen? Tar.gz kaputt?

tar schmeißt beim Erstellen ddes Backups des aktuellen Kernels einen Fehler
raus, so dass das Kernelupdate aus Sicherheitsgründen abgebrochen wird, da
ein Restaurieren des vorigen Kernels nicht sichergestellt werden, wenn
etwas beim Installieren des neuen Kernels fehlschlägt.

Warum tar allerdings Probleme mit obiger Datei hat, kann ich nicht sagen?

Du könntest mal auf der Kommandozeile tar-Testarchive erstellen und schauen,
ob der tar Fehlermeldungen ausgibt:

z. B. (jeweils in eine Zeile):

tar
-cvvf /root/test.tar /lib/modules/3.2.67-eisfair-1-SMP/kernel/drivers/block/paride/pcd.ko

tar
-cvvf /root/test.tar /lib/modules/3.2.67-eisfair-1-SMP/kernel/drivers/block/paride

Im Internet fand ich:

[Zitat]
Nachtrag: Im tar-Source findet man in src/create.c (das ist der Code, der
die Option "-c" implementiert) die Meldung "%s: File shrank by %s byte;
padding with zeros" in der Funktion dump_regular_file(). Die Funktion
besteht aus einer großen "while (size_left > 0)"-Schleife, in der mit der
Funktion safe_read() count (maximal bufsize) Bytes an Daten gelesen werden.
Wenn count != bufsize ist, hat die Datei nicht die erwartete Größe und tar
druckt die Meldung.

Das kann nur dann der Fall sein, wenn das Dateisystem die Größe falsch
zurückgibt oder die Datei die Größe während des Backups geändert hat.
[/Zitat]

Vielleicht wäre doch mal ein Check des Dateisystems angesagt.

Wenn Du die Datei /forcecheck anlegst, wird beim nächten Boot ein
Filesystemcheck durchgeführt:

touch /forcefsck

--
Gruss Marcus

[Marcus Roeckrath]

Hallo Thomas,

Thomas Bork wrote:

> Die tar-Meldung sagt aus, dass die Datei 11384 Bytes kleiner ist, als
> sie behauptet zu sein. tar füllt die Differenz deshalb mit Nullen auf.
> Das ergibt einen Exit-Code, der nicht 0 ist und das sagt mir, dass die
> Sicherung nicht korrekt gelaufen ist und ich breche ab.

Da es sich bei pcd.ko ja nicht um eine "veränderliche" Datei handelt, könnte
ein Dateisystemfehler vorliegen.

Hällst Du nicht auch einen Filesystemcheck für angebracht?

--
Gruss Marcus

[Stephan Manske]

marcus.r...@gmx.de (Marcus Roeckrath) schrieb:

> Danach wieder den normalen aktuellen -smp.
>
> Danach noch /va/install/packages/eiskernel-virt deinstallieren.

Da ich vor demselben Problem stand und den virt installieren mußte.
Wie bekomme ich den jetzt wieder weg? Deinstallieren per setup läßt
er sich nicht. :-(



Ciao, Stephan

--
E-Mail: ste...@manske-net.de - WWW: http://stephan.manske-net.de/ //
PGP 2.6.3i \X/
WindowsError:01E Timing error. Please wait. And wait. And wait.

[Marcus Roeckrath]

Hallo Stephan,

Stephan Manske wrote:

>> Danach wieder den normalen aktuellen -smp.
>>
>> Danach noch /va/install/packages/eiskernel-virt deinstallieren.

Da hatte ich mich damals vertippt.

Die Datei /var/install/packages/eiskernel-virt löschen.

--
Gruss Marcus

[Kay Martinen]

Am 05.05.2016 um 18:54 schrieb Marcus Roeckrath:
> Hallo Rolf,
>
> Rolf Bensch wrote:
>
>> bei der Installation des OpenSSL-Sicherheitsupdate werde ich auf ein
>> Kernel-Update hingewiesen. Beim Versuch einer Update-Installation von
>> eisfair Kernel (Linux 3.2.77-eisfair-1 SMP):
>>
>> Sorry, only installing on eisfair-1 systems with kernel
>> 3.2.75-eisfair-1
>> or
>> 3.2.77-eisfair-1!
>>
>> Aktuell läuft: base: 2.7.2 eiskernel: 2.5.2 (3.2.54-eisfair-1-SMP).

Bei mir kam beim base-update von 2.6.x auf 2.7.x irgendwann bei 2.71
(IMO) die Meldung das wg. devfsxxx ein neuer kernel nötig ist. Also
brach ich die restlichen base-updates ab und wollte den installieren,
aber dann kam ebenfalls obiges. Allerdings habe ich noch Eiskernel 2.12
und es IST ein SMP-System (2*Katmai/P3)

> Installiere zunächst den aktuellen Kernel in der -Virt-Version.

Mal ehrlich. Das finde ich irgendwie einen blöden Klimmzug. Geht das
nicht anders|einfacher?
Ich glaubte mit dem manuellen installieren (Setup: Paket-suche nach
"kernel") des kernels mit der geforderten version wäre das Problem
gelöst. Leider lag ich da falsch, aber ich sehe nicht ein warum?

> Danach wieder den normalen aktuellen -smp.
>
> Danach noch /va/install/packages/eiskernel-virt deinstallieren.

Ja, weil man einen einmal installierten kernel ja sonst auch nicht los
wird. Warum eigentlich nicht? Nur wegen der möglichen Gefahr das sich
ein script verzählt und in lilo dann NULL bootbare Kernel drin stehen?

> Und demnächst bitte am Ball bleiben.

Das finde ich etwas zu einfach "gemacht". Denn das ist nicht jedem
gegeben oder Möglich.

Mein Eis schlief jetzt eine weile; weil ich noch andere Systeme habe;
und danach, Siehe oben! Leider nicht das einzige aktuelle Problem dort.

Aber zum Update-Problem: es gibt für den Eis, ein Mailpaket, ein
ssmtp-paket u.v.m. ... WARUM gibt es eigentlich immer noch kein "Schick
mir eine mail wenn updates da sind"-Paket?

Beispiel Debian (auch wenn's nervt): einfach 'apticron' installiert und
geht! Das sieht dann so aus:

apticron report [Sun, 05 Jun 2016 20:31:34 +0200]
========================================================================

apticron has detected that some packages need upgrading on:

nathan
[ ip-adressen ]

The following packages are currently pending an upgrade:

[Liste mit paketname und version]

========================================================================

Package Details:

Lese Changelogs...

[Liste mit den Changelogs]

Wir hatten (hier?) IMHO schon mal das Thema eine liste upgradebarer
pakete in der shell zu erstellen. Was AFAIR damit nicht von Haus ging
war, diese liste nur zu schicken WENN updates da sind. Ich habe jetzt
vergessen wie es ging und weiß eh nicht wo genau da noch ein Problem
lauert. Aber, hat das Problem noch niemand angepackt, oder gibt es doch
schon so ein paket und ich kenne nur den namen nicht?

Kay
--
https://www.linuxcounter.net/cert/224140.png

[Marcus Roeckrath]

Hallo Kay,

Kay Martinen wrote:

> Bei mir kam beim base-update von 2.6.x auf 2.7.x irgendwann bei 2.71
> (IMO) die Meldung das wg. devfsxxx ein neuer kernel nötig ist. Also
> brach ich die restlichen base-updates ab und wollte den installieren,
> aber dann kam ebenfalls obiges. Allerdings habe ich noch Eiskernel 2.12
> und es IST ein SMP-System (2*Katmai/P3)
>
>> Installiere zunächst den aktuellen Kernel in der -Virt-Version.
>
> Mal ehrlich. Das finde ich irgendwie einen blöden Klimmzug. Geht das
> nicht anders|einfacher?

Das ist, wenn die CPU die entsprechenden Voraussetzungen hat, der schnellste
Weg.

1x aktueller Virt-Kernel, dann der gewünschte Kernel; fertig.

Ansonsten wären mehrere Kernelupdates nacheinander notwendig.

Die wirklich notwendigen Zwischenschritte - alle Versionen der Reihe nach zu
installieren, ist sowieso abslolut unnötig - hält Thomas unter der von ihm
geposteten URL für Notfälle bereit.

>> Danach noch /va/install/packages/eiskernel-virt deinstallieren.
>
> Ja, weil man einen einmal installierten kernel ja sonst auch nicht los
> wird. Warum eigentlich nicht? Nur wegen der möglichen Gefahr das sich
> ein script verzählt und in lilo dann NULL bootbare Kernel drin stehen?

Es ist immer nur ein Kernel installiert.

Ich hatte mich auch falsch ausgedrückt: Nicht DEINSTALLIEREN, sondern die
Datei löschen.

Der Kernel kann nicht deinstalliert werden; spätere Kernelupdates, egal
welchen Flavours, räumen alte Kernelbestandteile (alte
module-Verzeichnisse, ...) ab.

> Aber zum Update-Problem: es gibt für den Eis, ein Mailpaket, ein
> ssmtp-paket u.v.m. ... WARUM gibt es eigentlich immer noch kein "Schick
> mir eine mail wenn updates da sind"-Paket?

Dazu braucht es kein Paket.

Auf der Packeis (www.pack-eis.de) Seite gibt es den Punkt "Benachrichtigung
bei neuen Paketen", wo Du Deine Mailadresse eintragen kannst.

> Wir hatten (hier?) IMHO schon mal das Thema eine liste upgradebarer
> pakete in der shell zu erstellen. Was AFAIR damit nicht von Haus ging
> war, diese liste nur zu schicken WENN updates da sind.

War das hier in der Newsgroup?

Kannst Du das gegebenefalls in forum.nettworks.org raussuchen und den Link
schicken?

--
Gruss Marcus

[Marcus Roeckrath]

Hallo Kay,

Marcus Roeckrath wrote:

>> Wir hatten (hier?) IMHO schon mal das Thema eine liste upgradebarer
>> pakete in der shell zu erstellen. Was AFAIR damit nicht von Haus ging
>> war, diese liste nur zu schicken WENN updates da sind.
>
> War das hier in der Newsgroup?
>
> Kannst Du das gegebenefalls in forum.nettworks.org raussuchen und den Link
> schicken?

Folgendes sollte doch eine Liste der upgradable-Packages auf der Konsole
anzeigen:

eis # /var/install/bin/list-packages --batch upgradable
WARNING - Upgradable packages found (all)

Da steht es dann aber.

--
Gruss Marcus

[Marcus Roeckrath]

Hallo,

Marcus Roeckrath wrote:

> Folgendes sollte doch eine Liste der upgradable-Packages auf der Konsole
> anzeigen:
>
> eis # /var/install/bin/list-packages --batch upgradable
> WARNING - Upgradable packages found (all)
>
> Da steht es dann aber.

Ich war da etwas zu ungeduldig, braucht halt auf meinem System mit einer
Unmenge installierter Pakete eine ganze Weile.

Im Prinzip wäre es ein kleiner Skript in folgender Art als cron-Job:

/var/install/bin/list-packages --batch upgradable > <tempfile>

if (grep "Upgradable packages found" <tempfile>) ; then
cat <tempfile> | mail -s "Upgradable packages" root
fi

So mal schnell ins Unreine geschrieben.

--
Gruss Marcus

[Hilix]

Am 09.06.2016 um 01:37 schrieb Kay Martinen:
> Aber zum Update-Problem: es gibt für den Eis, ein Mailpaket, ein

> ssmtp-Paket u.v.m. ... WARUM gibt es eigentlich immer noch kein

> "Schick mir eine mail wenn updates da sind"-Paket?

...das wäre wirklich eine gute Sache!

Und bevor ich (oder andere User) beginne, mein eigenes "Schick
mir eine mail wenn updates da sind"-Paket zu basteln (bin kein
Programmierer), könnte es doch vonseiten der Distribution bereit
gestellt werden.
ssmtp nutze ich bereits, um mir Nachrichten über von clamav gefundene
Viren schicken zu lassen.

Grüße. / Hilmar.

[Helmut Backhaus]

Hallo Marcus!

Am 09.06.2016 um 08:58 schrieb Marcus Roeckrath:

>
> Im Prinzip wäre es ein kleiner Skript in folgender Art als cron-Job:
>
> /var/install/bin/list-packages --batch upgradable > <tempfile>
>
> if (grep "Upgradable packages found" <tempfile>) ; then
> cat <tempfile> | mail -s "Upgradable packages" root
> fi
>
> So mal schnell ins Unreine geschrieben.
>

Also, Dein Ansatz wird so nicht funktionieren, denn deine if Abfrage
wird *immer* wahr werden da folgendes bei der Ausgabe kommt, auch wenn
es nichts zum upgraden gibt:

eis1-cel06 # /var/install/bin/list-packages --batch upgradable
HIER! --> WARNING - Upgradable packages found (all) <-- HIER ist er!
OK - No packages updates in category 'upgradable' found.
Last check: 09.06.2016 14:46h

Ich bin gerade dabei was zu scripten ;-)

Ich melde mich später noch mal!

--
Gruß,
Helmut

[Marcus Roeckrath]

Hallo Helmut,

Helmut Backhaus wrote:

>> /var/install/bin/list-packages --batch upgradable > <tempfile>
>>
>> if (grep "Upgradable packages found" <tempfile>) ; then
>> cat <tempfile> | mail -s "Upgradable packages" root
>> fi
>>
>> So mal schnell ins Unreine geschrieben.
>
> Also, Dein Ansatz wird so nicht funktionieren, denn deine if Abfrage
> wird *immer* wahr werden da folgendes bei der Ausgabe kommt, auch wenn
> es nichts zum upgraden gibt:
>
> eis1-cel06 # /var/install/bin/list-packages --batch upgradable
> HIER! --> WARNING - Upgradable packages found (all) <-- HIER ist er!
> OK - No packages updates in category 'upgradable' found.
> Last check: 09.06.2016 14:46h

So ist das mit schnellen ungeprüften Hacks. :-)

Vielleicht dann:

if ! grep "No packages updates" <tempfile>) ; then

> Ich bin gerade dabei was zu scripten ;-)
>
> Ich melde mich später noch mal!

Fein.

--
Gruss Marcus

[Kay Martinen]

Am 09.06.2016 um 08:14 schrieb Marcus Roeckrath:

>
> Kay Martinen wrote:
>
>> aber dann kam ebenfalls obiges. Allerdings habe ich noch Eiskernel 2.12
>> und es IST ein SMP-System (2*Katmai/P3)
>>
>>> Installiere zunächst den aktuellen Kernel in der -Virt-Version.
>

> Das ist, wenn die CPU die entsprechenden Voraussetzungen hat, der schnellste
> Weg.

Und wenn nicht, was dann? HW, Siehe oben!

> 1x aktueller Virt-Kernel, dann der gewünschte Kernel; fertig.

Du meinst, ich muss den Virt-Kernel einmal booten?

Denn, ich habe eben den Virt-kernel installiert, was auch ging. Aber
dann direkt; ohne reboot; den SMP-Kernel installieren wollen, was dann
natürlich nicht mehr ging.

Jetzt habe ich ein wenig Sorge das mein Dual P3 System mit dem
Virt-kernel beim reboot voll auf die Fresse fliegt und ich dann nicht
mehr vor noch zurück komme!!!

> Ansonsten wären mehrere Kernelupdates nacheinander notwendig.
>
> Die wirklich notwendigen Zwischenschritte - alle Versionen der Reihe nach zu
> installieren, ist sowieso abslolut unnötig - hält Thomas unter der von ihm
> geposteten URL für Notfälle bereit.

Ichmussdawasverpasst haben. Welche url, wo gepostet?

> Es ist immer nur ein Kernel installiert.

Häh. EIS und OLDEIS sehe ich hier in LILO? Fragt sich nur was ich jetzt
unter OLDEIS habe...

> Der Kernel kann nicht deinstalliert werden; spätere Kernelupdates, egal
> welchen Flavours, räumen alte Kernelbestandteile (alte
> module-Verzeichnisse, ...) ab.

Hmmm, Ob-Highlander-Joke: "es kann nur einen geben" ;-)

>> Aber zum Update-Problem: es gibt für den Eis, ein Mailpaket, ein
>> ssmtp-paket u.v.m. ... WARUM gibt es eigentlich immer noch kein "Schick
>> mir eine mail wenn updates da sind"-Paket?
>
> Dazu braucht es kein Paket.
>
> Auf der Packeis (www.pack-eis.de) Seite gibt es den Punkt "Benachrichtigung
> bei neuen Paketen", wo Du Deine Mailadresse eintragen kannst.

Auch ich hab mich ungenau ausgedrückt. Ich meinte
"Updates-meiner-installierten-Pakete" und nicht "wenn irgendeines neu
ist" das ich evtl. nicht habe. Denn, ob ich nun libxyz installiert habe
weil irgendein Foobar-Programm die haben will - das weiß ich doch nicht.
Aus dem Kopf schon gar nicht. Will ich auch nicht! Dazu habe ich
Computer, DIE sollen das wissen, und nur dann laut geben wenn es zutrifft.

>> Wir hatten (hier?) IMHO schon mal das Thema eine liste upgradebarer
>> pakete in der shell zu erstellen. Was AFAIR damit nicht von Haus ging
>> war, diese liste nur zu schicken WENN updates da sind.
>
> War das hier in der Newsgroup?

Ich glaube schon. Kann aber auch ein Tip via mail gewesen sein
inhaltlich mit dem was du anschliessend postetest.

Auf der alten EIS-Installation hatte ich da mal einen cronjob. Aber die
läuft nicht mehr, und diese neue zickt auch noch wieder an mehreren
(swapper-crash, irq9-acpi-irgenwas error) ecken rum, nicht nur bei
obigen updates. Dabei ist es die gleiche HW wie früher auf der der EIS
ohne Probleme lief. Tendenziell würde ich die Probleme neueren
Kernelversionen an lasten, ist aber nur eine gefühlsmäßige Einschätzung.

N.B. Könnte man einen ECHT alten Kernel (2.4/2.6) UND einen Neuen (3.x)
Kernel im Wechsel starten - ließe sich das einfacher verifizieren. Denke
ich.

STOP, Ist mir schon klar das es wg. Libc u,a. so nicht funktionieren
würde... (Hmmm, Bootplatte im Wechselrahmen, evtl... mal sehen)

Kay
--
https://www.linuxcounter.net/cert/224140.png

[Marcus Roeckrath]

Hallo Kay,

Kay Martinen wrote:

>>>> Installiere zunächst den aktuellen Kernel in der -Virt-Version.
>>
>> Das ist, wenn die CPU die entsprechenden Voraussetzungen hat, der
>> schnellste Weg.
>

> Denn, ich habe eben den Virt-kernel installiert, was auch ging. Aber
> dann direkt; ohne reboot; den SMP-Kernel installieren wollen, was dann
> natürlich nicht mehr ging.

Natürlich booten.

> Jetzt habe ich ein wenig Sorge das mein Dual P3 System mit dem
> Virt-kernel beim reboot voll auf die Fresse fliegt und ich dann nicht
> mehr vor noch zurück komme!!!

Der vorige ist doch nun oldeis.

>> Ansonsten wären mehrere Kernelupdates nacheinander notwendig.
>>
>> Die wirklich notwendigen Zwischenschritte - alle Versionen der Reihe nach
>> zu installieren, ist sowieso abslolut unnötig - hält Thomas unter der von
>> ihm geposteten URL für Notfälle bereit.
>
> Ichmussdawasverpasst haben. Welche url, wo gepostet?

http://download.eisfair.org/tombork/old_kernel/

>> Es ist immer nur ein Kernel installiert.
>
> Häh. EIS und OLDEIS sehe ich hier in LILO? Fragt sich nur was ich jetzt
> unter OLDEIS habe...

Sagen wir es mal genauer:

Ein Update des Kernel-Paketes schiebt zur Sicherheit die Kernelbestandteile
des vorigen Kernels nach oldeis.

Nimmst Du übergangsweise einmal den Virt- und danach den SMP-Kernel ist
oldeis nun der Virt-Kernel.

Nochmal den SMP drübergebügelt, ist der Virt-Kernel aus der
Bootkonfiguration raus.

Die Dateien unter /var/install/packages/eiskernel-smp und eiskernel-virt
bewirken nun, dass Dir die Update-Routine bei der nächsten
Kernelveröffentlichung nun sowohl den VIRT- als auch den SMP-Kernel zum
Update anbieten wird.

Damit das nicht geschieht, sollte man die Info-Datei des Virt-Kernels
löschen.

> Auch ich hab mich ungenau ausgedrückt. Ich meinte
> "Updates-meiner-installierten-Pakete" und nicht "wenn irgendeines neu
> ist" das ich evtl. nicht habe. Denn, ob ich nun libxyz installiert habe
> weil irgendein Foobar-Programm die haben will - das weiß ich doch nicht.
> Aus dem Kopf schon gar nicht. Will ich auch nicht! Dazu habe ich
> Computer, DIE sollen das wissen, und nur dann laut geben wenn es zutrifft.
>
>>> Wir hatten (hier?) IMHO schon mal das Thema eine liste upgradebarer
>>> pakete in der shell zu erstellen. Was AFAIR damit nicht von Haus ging
>>> war, diese liste nur zu schicken WENN updates da sind.
>>
>> War das hier in der Newsgroup?
>
> Ich glaube schon. Kann aber auch ein Tip via mail gewesen sein
> inhaltlich mit dem was du anschliessend postetest.

Helmut strickt ja schon ein Skript, wie er angekündigt hat.

> N.B. Könnte man einen ECHT alten Kernel (2.4/2.6) UND einen Neuen (3.x)
> Kernel im Wechsel starten - ließe sich das einfacher verifizieren. Denke
> ich.
>
> STOP, Ist mir schon klar das es wg. Libc u,a. so nicht funktionieren
> würde...

Genau das.

--
Gruss Marcus

[Helmut Backhaus]

Am 09.06.2016 um 20:52 schrieb Marcus Roeckrath:

>> Ich glaube schon. Kann aber auch ein Tip via mail gewesen sein
>> inhaltlich mit dem was du anschliessend postetest.
>
> Helmut strickt ja schon ein Skript, wie er angekündigt hat.
>

Nicht drängeln! :-))
Ich bin eigentlich fertig, aber da ist noch ein blöder Fehler drin. Ich
bin aber wohl auf dem Richtigen Weg ...


--
Gruß,
Helmut

[Marcus Roeckrath]

Hallo Helmut,

Helmut Backhaus wrote:

> Nicht drängeln! :-))

Natürlich nicht; es gilt - wie immer - Weihnachten.

> Ich bin eigentlich fertig, aber da ist noch ein blöder Fehler drin. Ich
> bin aber wohl auf dem Richtigen Weg ...

Du kannst uns ja am aktuellen Stand teilhaben, um nach dem blöden Fehler zu
suchen.

--
Gruss Marcus

[Helmut Backhaus]

Hallo Marcus!

Am 09.06.2016 um 22:34 schrieb Marcus Roeckrath:
> Hallo Helmut,
>
> Helmut Backhaus wrote:
>
>> Nicht drängeln! :-))
>
> Natürlich nicht; es gilt - wie immer - Weihnachten.

Dann müssen wir uns nur noch auf's Jahr einigen ...

>
>> Ich bin eigentlich fertig, aber da ist noch ein blöder Fehler drin. Ich
>> bin aber wohl auf dem Richtigen Weg ...
>
> Du kannst uns ja am aktuellen Stand teilhaben, um nach dem blöden Fehler zu
> suchen.
>

Nur ruhig, ich glaube ich habe fertig!

Das folgende Script habe ich unter unter "/usr/local/bin/update-chk.sh"
abgelegt und Ausführbar gemacht "chmod +x /usr/local/bin/update-chk.sh".
Dann habe ich einen Eintrag in die Datei "/etc/profile" in die Zeile 38
hinter:

if [ ${LOGNAME} = root ]
then
--> source /usr/local/bin/update-chk.sh

gemacht!

Damit wird, wenn eine Konsole als root geöffnet wird, dass Script
gestartet. Eine Ausgabedatei wird in "/tmp/update-chk.dat" abgelegt. Auf
Basis dieser Datei wird auch geprüft, ob eine Prüfung durchgefüht wird.
Ich habe den Wert auf einmal am Tag gesetzt "tcheck=$((60*60*24))". Wenn
gewünscht kann dieser Wert auch auf z.B. "tcheck=$((60*60*24*7)) gesetzt
werde (eine Woche).

Ich habe mich für diesen Weg entschieden, weil "mail" nicht zu den
Bordmitteln gehört (oder habe ich da etwas übersehen?). Das Script läuft
also "out of the box"!

Eine Mail-Variante habe ich auch noch in der Pipeline aber das kann ich
nicht testen, weil ich keinen Eis 1 mit Mail habe. Das muss ich mir dann
erst mal installieren.

OK, genug geschwafelt! Hier das Script:
Bitte mit den Umbrüchen aufpassen!!!

-->

#!/bin/bash

########################################################################
# update-chk.sh
# ein mini Script um auf einem Eisfair 1 beim log in als root zu prüfen
# ob upgrades für den Server vorliegen.
# Das Script kann in die Datei "/etc/profile" eingebunden werden um es
# beim login ausführen zu lassen.
#
# Ich habe es in Zeile 38 hinter:
# if [ ${LOGNAME} = root ]
# then
# source /usr/local/bin/update-chk.sh
# eingebunden!
# So wird es nur beim Login als root gestartet und das auch nur einmal
# Täglich.
#
# Autor : Helmut Backhaus
# Erstell am: 09.06.2016
# Geändert am: 09.06.2016
# Version : 0.0.1
########################################################################

# set -xv

ausgabe()
{
sed -i '/WARNING/d' $chkfile
lastcheck=$(cat $chkfile | grep -i 'last check')
sed -i '1d' $chkfile
count=$(cat $chkfile | wc -l)
if [ $count -gt 0 ] ; then
/usr/local/bin/colecho "There are $count upgradable packages
available!" rd
/usr/local/bin/colecho "For more info run Setup!" rd
echo
else
/usr/local/bin/colecho "There are no upgradable packages available!" gn
/usr/local/bin/colecho "Your System is fine!" gn
echo
fi
}

chkfile="/tmp/update-chk.dat"
tnow=$(date "+%s")
tcheck=$((60*60*24))

if ! [ -f $chkfile ] ; then
/usr/local/bin/colecho "There is no chk file for upgrade check" gn
/usr/local/bin/colecho "Will be done, please wait ..." gn
echo
/var/install/bin/list-packages --batch upgradable > $chkfile
ausgabe
checkvar="yes"
else
tdatei=$(stat -c %Z $chkfile)
alter=$(( $tnow - $tdatei ))
fi

if [ -z $checkvar ] && [ $alter -ge $tcheck ] ; then
rm $chkfile
/usr/local/bin/colecho "Upgrade check will be done!" gn
/usr/local/bin/colecho "Please wait ..." gn
echo
/var/install/bin/list-packages --batch upgradable > $chkfile
ausgabe
else
if [ -z $checkvar ] && [ -n $alter ] ; then
/usr/local/bin/colecho "Updates are allready checked today!" gn
echo
fi
fi
<--

Wie immer feedback Erwünscht!!


--
Gruß,
Helmut

[Marcus Roeckrath]

Hallo Helmut,

Helmut Backhaus wrote:

>>> Nicht drängeln! :-))
>>
>> Natürlich nicht; es gilt - wie immer - Weihnachten.
>
> Dann müssen wir uns nur noch auf's Jahr einigen ...

Das lassen wir mal - wie üblich - offen.

> Das folgende Script habe ich unter unter "/usr/local/bin/update-chk.sh"
> abgelegt und Ausführbar gemacht "chmod +x /usr/local/bin/update-chk.sh".
> Dann habe ich einen Eintrag in die Datei "/etc/profile" in die Zeile 38
> hinter:
>
> if [ ${LOGNAME} = root ]
> then
> --> source /usr/local/bin/update-chk.sh
>
> gemacht!
>
> Damit wird, wenn eine Konsole als root geöffnet wird, dass Script
> gestartet.

Erzwingt also, dass man sich regelmäßig auf dem Server einloggt.

> Ich habe mich für diesen Weg entschieden, weil "mail" nicht zu den
> Bordmitteln gehört (oder habe ich da etwas übersehen?).

Da fragst Du mich was, ich habe nur Server mit Mailpaket.

Es gibt doch viele Dienste/Pakete, die Mails an root schreiben; die müssten
doch dann immer im Nirvana landen, wenn kein Mailpaket installiert ist.

> Das Script läuft
> also "out of the box"!
>
> Eine Mail-Variante habe ich auch noch in der Pipeline aber das kann ich
> nicht testen, weil ich keinen Eis 1 mit Mail habe. Das muss ich mir dann
> erst mal installieren.

Oder Du schickst sie mir zu und ich teste das für Dich.

> OK, genug geschwafelt! Hier das Script:
> Bitte mit den Umbrüchen aufpassen!!!

Ich schaue mir das heute nachmittag mal genau an und lasse es mal laufen.

Danke für Deine Arbeit.

--
Gruss Marcus

[Marcus Roeckrath]

Hallo Helmut,

Helmut Backhaus wrote:

> Ich habe mich für diesen Weg entschieden, weil "mail" nicht zu den
> Bordmitteln gehört (oder habe ich da etwas übersehen?).

Im Installationsmedium ist kein mail-Programm enthalten; also muss man
zumindestens eines der Mailpakete installieren.

--
Gruss Marcus

[Helmut Backhaus]

Moin Marcus!

Am 10.06.2016 um 08:11 schrieb Marcus Roeckrath:
> Hallo Helmut,
>
> Helmut Backhaus wrote:
>
>>>> Nicht drängeln! :-))
>>>
>>> Natürlich nicht; es gilt - wie immer - Weihnachten.
>>
>> Dann müssen wir uns nur noch auf's Jahr einigen ...
>
> Das lassen wir mal - wie üblich - offen.

;-)

>
>> Das folgende Script habe ich unter unter "/usr/local/bin/update-chk.sh"
>> abgelegt und Ausführbar gemacht "chmod +x /usr/local/bin/update-chk.sh".
>> Dann habe ich einen Eintrag in die Datei "/etc/profile" in die Zeile 38
>> hinter:
>>
>> if [ ${LOGNAME} = root ]
>> then
>> --> source /usr/local/bin/update-chk.sh
>>
>> gemacht!
>>
>> Damit wird, wenn eine Konsole als root geöffnet wird, dass Script
>> gestartet.
>
> Erzwingt also, dass man sich regelmäßig auf dem Server einloggt.
>

Ob man das als erzwingen bezeichnen kann??
für mich ist das normal und ein Hinweis das da was zu "upgraden" liegt,
mehr nicht.

>> Ich habe mich für diesen Weg entschieden, weil "mail" nicht zu den
>> Bordmitteln gehört (oder habe ich da etwas übersehen?).
>
> Da fragst Du mich was, ich habe nur Server mit Mailpaket.
>
> Es gibt doch viele Dienste/Pakete, die Mails an root schreiben; die müssten
> doch dann immer im Nirvana landen, wenn kein Mailpaket installiert ist.
>

Na ja, ich war mir nur nicht sicher. Aber das ist ja nun geklärt, dass
im Standard kein "Mail" vorhanden ist.

>> Das Script läuft
>> also "out of the box"!
>>
>> Eine Mail-Variante habe ich auch noch in der Pipeline aber das kann ich
>> nicht testen, weil ich keinen Eis 1 mit Mail habe. Das muss ich mir dann
>> erst mal installieren.
>
> Oder Du schickst sie mir zu und ich teste das für Dich.

Dann lerne ich aber nichts dabei!
Aber Trotzdem danke für das Angebot, vielleicht komme ich ja noch drauf
zurück. ;-)

>
>> OK, genug geschwafelt! Hier das Script:
>> Bitte mit den Umbrüchen aufpassen!!!
>
> Ich schaue mir das heute nachmittag mal genau an und lasse es mal laufen.
>
> Danke für Deine Arbeit.
>

Wenn es jemanden hilft ...!

Ich habe hier schon so viel bekommen!!!


--
Gruß,
Helmut

[Holger Bruenjes]

Hallo Helmut

Am 2016-06-10 um 13:12 schrieb Helmut Backhaus:

> Dann lerne ich aber nichts dabei!

OK, colecho sollte nicht mehr benutzt werden, die eislib stellt
mecho bereit


http://www.eisfair.org/fileadmin/eisfair/devdoc/node10.html#SECTION001014000000000000000

. /var/install/include/eislib


mecho --info
mecho --warn
mecho --error


Holger

[Helmut Backhaus]

Hallo Holger!

Am 10.06.2016 um 13:32 schrieb Holger Bruenjes:
> Hallo Helmut
>
> Am 2016-06-10 um 13:12 schrieb Helmut Backhaus:
>
>> Dann lerne ich aber nichts dabei!
>
> OK, colecho sollte nicht mehr benutzt werden, die eislib stellt
> mecho bereit
>

So etwas meine ich! Danke Holger!

>
> http://www.eisfair.org/fileadmin/eisfair/devdoc/node10.html#SECTION001014000000000000000

Wie war das mit den Geistern, die ich rief?

>
> . /var/install/include/eislib
>

Das bedeutet, dass ich, wenn ich sie nutzen will, die "eislib immer
Sourcen muss, richtig?

Und gleich noch einen, diese Notierungen sind identisch?
source /var/install/include/eislib
. /var/install/include/eislib

Zumindest habe ich das so gelesen, aber ist das wirklich so?

>
> mecho --info
> mecho --warn
> mecho --error
>

So wie ich das sehe, kommt da für mich auch noch "techo" dazu ...

Danke für den Hinweis und den Link!!


--
Gruß,
Helmut

[Helmut Backhaus]

Sorry, falscher Fehler!!

Am 10.06.2016 um 14:10 schrieb Helmut Backhaus:

Das hier ist falsch!!!

> Und gleich noch einen, diese Notierungen sind identisch?
> source /var/install/include/eislib

> .. /var/install/include/eislib

>
> Zumindest habe ich das so gelesen, aber ist das wirklich so?
>

Sollte werden:
source /var/install/include/eislib
. /var/install/include/eislib

Sorry noch mal!!


--
Gruß,
Helmut

[Marcus Roeckrath]

Hallo Helmut,

Helmut Backhaus wrote:

> Das hier ist falsch!!!
>> Und gleich noch einen, diese Notierungen sind identisch?
>> source /var/install/include/eislib
>> .. /var/install/include/eislib
>>
>> Zumindest habe ich das so gelesen, aber ist das wirklich so?
>>
>
> Sollte werden:
> source /var/install/include/eislib
> . /var/install/include/eislib

IMHO ist das völlig egal; ich verwende immer den .

--
Gruss Marcus

[Marcus Roeckrath]

Hallo Helmut,

Helmut Backhaus wrote:

>> . /var/install/include/eislib
>>
> Das bedeutet, dass ich, wenn ich sie nutzen will, die "eislib immer
> Sourcen muss, richtig?

Genau; so kann man allgemein verwendbare Funktionen usw. in einer Dtei
vorhalten und dann beliebig in anderen Skripten verwenden.

Die eisfair-Skripte sourcen z. B. auch die Konfigurationsdateien, die wie
bash-Skripte (Variablenzuweisungen) aufgebaut sind.

--
Gruss Marcus

[Helmut Backhaus]

Hallo Holger, hallo Marcus!

Am 10.06.2016 um 13:32 schrieb Holger Bruenjes:

> Hallo Helmut
>
> Am 2016-06-10 um 13:12 schrieb Helmut Backhaus:
>
>> Dann lerne ich aber nichts dabei!
>
> OK, colecho sollte nicht mehr benutzt werden, die eislib stellt
> mecho bereit
>

Wenn ich fragen darf, warum ist das so?
Ich habe schon relativ viel mit "colecho" unter Fli4l gemacht und da ist
das natürlich das Kommando meiner Wahl.

>
> http://www.eisfair.org/fileadmin/eisfair/devdoc/node10.html#SECTION001014000000000000000
>
> .. /var/install/include/eislib
>

jetzt weiß ich auch, wo ich das Kommando mit den zwei Punkten her hatte
;-) !

>
> mecho --info
> mecho --warn
> mecho --error
>
>

Das habe ich nun so umgesetzt, eine überarbeitete Version könnt ihr euch
hier ziehen:
http://www.112-ausbildung.org/download/eis/update-chk.sh

Ob das aber so bleiben wird, weiß ich noch nicht. Mich stört die lange
Wartezeit wenn auf neu Pakete geprüft wird. Ich denke gerade über eine
"cron Lösung" nach, beim login wird dann nur noch das Ergebnis
ausgewertet. Das könnte eleganter sein.

--
Gruß,
Helmut

[Marcus Roeckrath]

Hallo Helmut,

Helmut Backhaus wrote:

>>

http://www.eisfair.org/fileadmin/eisfair/devdoc/node10.html#SECTION001014000000000000000
>>
>> .. /var/install/include/eislib
>>
> jetzt weiß ich auch, wo ich das Kommando mit den zwei Punkten her hatte
> ;-) !

Wo auf dieser Seite? Ich kann da nichts mit ".." fürs inkludieren sehen.

> Das habe ich nun so umgesetzt, eine überarbeitete Version könnt ihr euch
> hier ziehen:
> http://www.112-ausbildung.org/download/eis/update-chk.sh
>
> Ob das aber so bleiben wird, weiß ich noch nicht. Mich stört die lange
> Wartezeit wenn auf neu Pakete geprüft wird. Ich denke gerade über eine
> "cron Lösung" nach, beim login wird dann nur noch das Ergebnis
> ausgewertet. Das könnte eleganter sein.

Auf meiner privaten Kiste mit 498 installierten Paketen dauert das gut 5
Minuten.

--
Gruss Marcus

[Helmut Backhaus]

Hallo Marcus!

Am 10.06.2016 um 16:49 schrieb Marcus Roeckrath:
> Hallo Helmut,
>
> Helmut Backhaus wrote:
>
>>>
> http://www.eisfair.org/fileadmin/eisfair/devdoc/node10.html#SECTION001014000000000000000
>>>
>>> .. /var/install/include/eislib
>>>
>> jetzt weiß ich auch, wo ich das Kommando mit den zwei Punkten her hatte
>> ;-) !
>
> Wo auf dieser Seite? Ich kann da nichts mit ".." fürs inkludieren sehen.

Na direkt hier!
7 Zeile höher!

>
>> Das habe ich nun so umgesetzt, eine überarbeitete Version könnt ihr euch
>> hier ziehen:
>> http://www.112-ausbildung.org/download/eis/update-chk.sh
>>
>> Ob das aber so bleiben wird, weiß ich noch nicht. Mich stört die lange
>> Wartezeit wenn auf neu Pakete geprüft wird. Ich denke gerade über eine
>> "cron Lösung" nach, beim login wird dann nur noch das Ergebnis
>> ausgewertet. Das könnte eleganter sein.
>
> Auf meiner privaten Kiste mit 498 installierten Paketen dauert das gut 5
> Minuten.
>

Also siehst du auch eine Berechtigung in meine Überlegung?
Mal sehen, heute Abend ... eine Grundlegende Idee wie ich das umsetze
habe ich schon. Und da könnte man dann wahlweise oder beides (Mail -
Konsole) integrieren (glaube ich).


--
Gruß,
Helmut

[Marcus Roeckrath]

Hallo Helmut,

Helmut Backhaus wrote:

> Dann habe ich einen Eintrag in die Datei "/etc/profile" in die Zeile 38
> hinter:
>
> if [ ${LOGNAME} = root ]
> then
> --> source /usr/local/bin/update-chk.sh
>
> gemacht!

Eines sollte man noch beachten: Was passiert, wenn jemand kurz
hintereinander zwei Sessions aufmacht?

--
Gruss Marcus

[Marcus Roeckrath]

Gibt garantiert Fragen, wenn nach dem Login Minuten vergehen, bis man
"arbeitsfähig" ist.

Ist ein mail-Binary vorhanden, kann bei Starten als cronjob auch sofort bei
Bedarf die Mail verschickt werden.

--
Gruss Marcus

[Kay Martinen]

Am 10.06.2016 um 17:57 schrieb Marcus Roeckrath:

>
> Helmut Backhaus wrote:
>> habe ich schon. Und da könnte man dann wahlweise oder beides (Mail -
>> Konsole) integrieren (glaube ich).

Wäre es nicht die beste Lösung; spätestens beim Installieren (wenn es
mal Paket wird) oder ersten Start auf Existenz eines Mailpakets/binary
zu prüfen und dann direkt cronjob + mailnachricht zu nehmen. Erst wenn
das nicht klappt die Login-check methode.

> Gibt garantiert Fragen, wenn nach dem Login Minuten vergehen, bis man
> "arbeitsfähig" ist.

Da würde ich mich allerdings auch schön bedanken und fragen wie das nun
kommt.

> Ist ein mail-Binary vorhanden, kann bei Starten als cronjob auch sofort bei
> Bedarf die Mail verschickt werden.

Das würde ich eh vorziehen. Ein Server der unbeaufsichtigt läuft und
seine Befindlichkeiten NICHT mindestens per mail mitteilt ist m.E. ein
unding.

Kay
--
https://www.linuxcounter.net/cert/224140.png

[Kay Martinen]

Darf ich raten, Race-condition? Oder gilt das nur im Kernel so?

Wenn ich ernsthaft per ssh mit einem server arbeite mache ich eine
session zum arbeiten auf und eine zweite für ein 'tail' 'watch' o.ä. auf
das logfile oder einen befehl.

Kay
--
https://www.linuxcounter.net/cert/224140.png

[Marcus Roeckrath]

Hallo Helmut,

Helmut Backhaus wrote:

> Das folgende Script habe ich unter unter "/usr/local/bin/update-chk.sh"
> abgelegt und Ausführbar gemacht "chmod +x /usr/local/bin/update-chk.sh".
> Dann habe ich einen Eintrag in die Datei "/etc/profile" in die Zeile 38
> hinter:
>
> if [ ${LOGNAME} = root ]
> then
> --> source /usr/local/bin/update-chk.sh
>
> gemacht!

Es ist nicht ausgeschlossen, dass diese Datei durch ein Base-Update
überschreiben wird.

--
Gruss Marcus

[Helmut Backhaus]

Hallo Kay!

Am 10.06.2016 um 19:21 schrieb Kay Martinen:
> Am 10.06.2016 um 17:58 schrieb Marcus Roeckrath:
>>
>> Helmut Backhaus wrote:
>>
>>> Dann habe ich einen Eintrag in die Datei "/etc/profile" in die Zeile 38
>>> hinter:
>>>
>>> if [ ${LOGNAME} = root ]
>>> then
>>> --> source /usr/local/bin/update-chk.sh
>>>
>>> gemacht!
>>
>> Eines sollte man noch beachten: Was passiert, wenn jemand kurz
>> hintereinander zwei Sessions aufmacht?
>
> Darf ich raten, Race-condition? Oder gilt das nur im Kernel so?

Da hätte ich auch eher keine Probleme gesehen ...
Aber Was meinst Du mit "Race-condition"?

>
> Wenn ich ernsthaft per ssh mit einem server arbeite mache ich eine
> session zum arbeiten auf und eine zweite für ein 'tail' 'watch' o.ä. auf
> das logfile oder einen befehl.
>

So, oder so ähnlich hatte ich mir das auch gedacht ...


--
Gruß,
Helmut

[Marcus Roeckrath]

Hallo Kay,

Kay Martinen wrote:

>> Eines sollte man noch beachten: Was passiert, wenn jemand kurz
>> hintereinander zwei Sessions aufmacht?
>
> Darf ich raten, Race-condition? Oder gilt das nur im Kernel so?

Das Checkskript arbeitet dann erstmal auf der gleichen temporären Datei; das
später gestartete Skript findet diese dann schon vor und nimmt an, dass der
Check aktuell ist und gibt ein Ergebnis aus, auch wenn Prozess 1 diese noch
garnicht komplett mit Daten gefüllt hat.

Prozess 2 kann aber auch so schnell auf Prozess 1 folgen, dass die temporäre
Datei noch nicht existiert, dann wird list-packages zweimal gestartet.

Welche Auswirkungen das hat, müsste man in list-packages untersuchen;
zumindest werden hardcodete Temp-Files genutzt, so dass ein Doppelstart
nicht anzuraten ist.

--
Gruss Marcus

[Helmut Backhaus]

Hallo Kay!

Am 10.06.2016 um 19:18 schrieb Kay Martinen:
> Am 10.06.2016 um 17:57 schrieb Marcus Roeckrath:
>>
>> Helmut Backhaus wrote:
>>> habe ich schon. Und da könnte man dann wahlweise oder beides (Mail -
>>> Konsole) integrieren (glaube ich).
>
> Wäre es nicht die beste Lösung; spätestens beim Installieren (wenn es
> mal Paket wird) oder ersten Start auf Existenz eines Mailpakets/binary
> zu prüfen und dann direkt cronjob + mailnachricht zu nehmen. Erst wenn
> das nicht klappt die Login-check methode.
>

Na ja, ich wollte eben mit "Standard Bordmitteln" auskommen und "mail"
gehört nun mal nicht dazu. Aber ich werde das so machen, das beides
geht. Und wenn auf die Mail nicht reagiert worden ist, bekommt man das
beim anmelden dann eben nochmal vorgelegt.

Mein größeres Problem ist, wie bekomme ich das ganze zurückgesetzt wenn
die Updates gemacht sind und noch kein neuer cronlauf statt gefunden
hat, dass macht mir viel mehr "Kopfschmerzen"!

>
>> Gibt garantiert Fragen, wenn nach dem Login Minuten vergehen, bis man
>> "arbeitsfähig" ist.
>
> Da würde ich mich allerdings auch schön bedanken und fragen wie das nun
> kommt.

Ja ja, macht mich nur nieder ;-)
Ich habs ja selbst gemerkt und das Script für den cron habe ich auch
schon fertig, dass läuft.

>
>> Ist ein mail-Binary vorhanden, kann bei Starten als cronjob auch sofort bei
>> Bedarf die Mail verschickt werden.
>
> Das würde ich eh vorziehen. Ein Server der unbeaufsichtigt läuft und
> seine Befindlichkeiten NICHT mindestens per mail mitteilt ist m.E. ein
> unding.
>

Ich nicht unbedingt, gerade wenn ich hier die ständigen "certivikats"
Aktionen lese wird mir ganz anders ...

Aber ich gehe da mal dabei und hoffe eine Lösung zu finden ...

--
Gruß,
Helmut

[Olaf Jaehrling]

Hallo Marcus,

Du meinst die /etc/profile?

Das ist in den 15 Jahren, die ich eisfair-1 nutze noch nie passiert.
Zumindest sind meine Einträge immer noch da.
lt. Header zwar 2013 geändert aber meine alten Einträge sind noch da.
# Creation : 2001-08-08 fm
# Last Update: 2013-05-01 hbfl

z.B.
# New environment setting added by Smart Power on Thu Nov 04 22:13:05
CET 2010 1 .
# The unmodified version of this file is saved in /etc/profile347422255.
# Do NOT modify these lines; they are used to uninstall.
LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/opt/smartpower_new/lib"
export LD_LIBRARY_PATH
# End comments by InstallAnywhere on Thu Nov 04 22:13:05 CET 2010 1.



Gruß

Olaf

>

[Marcus Roeckrath]

Hallo Helmut,

Helmut Backhaus wrote:

>>> Eines sollte man noch beachten: Was passiert, wenn jemand kurz
>>> hintereinander zwei Sessions aufmacht?
>>

> Da hätte ich auch eher keine Probleme gesehen ...

Ich schon.

Ich verwende in Skripten, die besser nicht mehrfach (parallel) gestartet
werden dürfen, folgenden Code:

if [ -f /tmp/my_skript.running ] ; then
  exit 1
fi

touch /tmp/my_skript.running

[...]

rm -f /tmp/my_pic_fetch.running

> Aber Was meinst Du mit "Race-condition"?

https://de.wikipedia.org/wiki/Race_Condition

Hier würde Dein Skript bzw. auch das von diesem dann mehrfach gestartete
list-packages die gleichen Dateien manipulieren.

--
Gruss Marcus

[Marcus Roeckrath]

Hallo Olaf,

Olaf Jaehrling wrote:

>> Es ist nicht ausgeschlossen, dass diese Datei durch ein Base-Update
>> überschreiben wird.
>
> Du meinst die /etc/profile?
>
> Das ist in den 15 Jahren, die ich eisfair-1 nutze noch nie passiert.
> Zumindest sind meine Einträge immer noch da.

Ok, ich versuche Änderungen an soclhen Standarddateien zu vermeiden.

Auf Nummer Sicher könnte man bei Benutzung der /root/.profile gehen.

--
Gruss Marcus

[Marcus Roeckrath]

Hallo Helmut,

Helmut Backhaus wrote:

> Mein größeres Problem ist, wie bekomme ich das ganze zurückgesetzt wenn
> die Updates gemacht sind und noch kein neuer cronlauf statt gefunden
> hat, dass macht mir viel mehr "Kopfschmerzen"!

Wenn ein Mail-Program erkannt wird, läuft ja alles üer den cron-Job, d. h.
der User wird nicht mit möglicherweise inaktuellen Updates belästigt.

Ist also nur ein Problem bei der Loginmethode:

Hier könnte man doch prüfen, ob die Datei /var/log/log.eisinstall neueren
Datums als Deine Check-Datei ist.

Wenn ja, dann keine Meldung ausgeben, auch wenn dabei nicht festgestellt
werden kann, ob wirklich zwischenzeitlich Updates vorgenommen wurde oder
etwas anderes installiert wurde.

Alles andere wäre IMHO ein viel zu großer Aufwand.

--
Gruss Marcus

[Olaf Jaehrling]

Hi Marcus,

Marcus Roeckrath schrieb am 10.06.2016 um 20:15:
> Hallo Olaf,
>
> Olaf Jaehrling wrote:
>
>>> Es ist nicht ausgeschlossen, dass diese Datei durch ein Base-Update
>>> überschreiben wird.
>>
>> Du meinst die /etc/profile?
>>

>

> Ok, ich versuche Änderungen an soclhen Standarddateien zu vermeiden.

Jupp, ich auch, aber es gibt Programme, die nur darauf zugreifen, weil
ebend halt Systemübergreifend. So auch mein UPS-Programm. Daran habe ich
es ja gemerkt :)

>
> Auf Nummer Sicher könnte man bei Benutzung der /root/.profile gehen.

Das gilt dann aber auch nur für root.

Gruß

Olaf

>

[Marcus Roeckrath]

Hallo Olaf,

Olaf Jaehrling wrote:

>> Auf Nummer Sicher könnte man bei Benutzung der /root/.profile gehen.
>
> Das gilt dann aber auch nur für root.

Mit der Systempflege hat ja ein normaler User auch nichts zu tun.

--
Gruss Marcus

[Fabian Törner]

Hallo Marcus,

Am 10.06.2016 um 21:02 schrieb Marcus Roeckrath:
>> Das gilt dann aber auch nur für root.
>
> Mit der Systempflege hat ja ein normaler User auch nichts zu tun.

wenn man es gaanz genau nimmt, dann root eigentlich auch nicht ....
Beim eis wird das nur etwas flexibler ausgelegt :)

Viele Grüße
Fabian

[Christoph Schulz]

Hallo!

Marcus Roeckrath schrieb:

> Ich verwende in Skripten, die besser nicht mehrfach (parallel) gestartet
> werden dürfen, folgenden Code:
>
> if [ -f /tmp/my_skript.running ] ; then
> exit 1
> fi
>
> touch /tmp/my_skript.running

Das ist aber auch eine "race condition", da Testen-und-Setzen nicht atomar
ist. Es könnte sein, dass zwei Skript-Prozesse gleichzeitig starten, beide
feststellen, dass die Datei /tmp/my_skript.running nicht existiert, beide
diese Datei via "touch" erzeugen (einer erzeugt, der andere aktualisiert nur
den Zeitstempel der letzten Änderung) und dann beide parallel ausgeführt
werden.

Eine funktionierende Möglichkeit unter Linux ist, eine symbolische
Verknüpfung zu erzeugen, weil das immer atomar ist:

if ! ln -s /tmp/my_skript.$$ /tmp/my_skript.running 2>/dev/null; then
exit 1
fi
[...]
rm -f /tmp/my_skript.running

Man beachte, dass das Ziel der Verknüpfung (also /tmp/my_skript.$$) gar
nicht existieren muss.

Will man auf Nummer sicher gehen, dass das Aufräumen nicht vergessen wird,
steckt man das Löschen in einen Shell-Exit-Hook:

trap "[ \"\`readlink /tmp/my_skript.running\`\" = /tmp/my_skript.$$ ] &&
rm -f /tmp/my_skript.running" EXIT
if ! ln -s /tmp/my_skript.$$ /tmp/my_skript.running 2>/dev/null; then
exit 1
fi
[...]

Dann wird immer aufgeräumt, auch wenn das Skript abbricht oder durch ein
Signal wie SIGHUP beendet wird. Der etwas kompliziert anmutende Vergleich
mit readlink stellt sicher, dass die /tmp/my_skript.running-Verknüpfung nur
dann gelöscht wird, wenn das Skript sie auch besitzt, was an der Prozess-ID
($$) festgemacht wird, die im Ziel der symbolischen Verknüpfung kodiert ist.
(Ein Zurücksetzen des Shell-Exit-Hooks direkt vor dem "exit 1" via "trap -
EXIT" ist nicht sicher, weil das Skript zwischen einem fehlgeschlagenem ln-
Aufruf und dem trap-Befehl von außen durch ein Signal beendet werden
könnte.)


Viele Grüße,
--
Christoph Schulz
[fli4l-Team]

[Marcus Roeckrath]

Hallo Christoph,

Christoph Schulz wrote:

> Eine funktionierende Möglichkeit unter Linux ist, eine symbolische
> Verknüpfung zu erzeugen, weil das immer atomar ist:
>
> if ! ln -s /tmp/my_skript.$$ /tmp/my_skript.running 2>/dev/null; then
> exit 1
> fi
> [...]
> rm -f /tmp/my_skript.running
>
> Man beachte, dass das Ziel der Verknüpfung (also /tmp/my_skript.$$) gar
> nicht existieren muss.
>
> Will man auf Nummer sicher gehen, dass das Aufräumen nicht vergessen wird,
> steckt man das Löschen in einen Shell-Exit-Hook:
>
> trap "[ \"\`readlink /tmp/my_skript.running\`\" = /tmp/my_skript.$$ ] &&
> rm -f /tmp/my_skript.running" EXIT
> if ! ln -s /tmp/my_skript.$$ /tmp/my_skript.running 2>/dev/null; then
> exit 1
> fi
> [...]

Vielen Dank für Deine sehr aufschlussreichen Erläuterungen.

--
Gruss Marcus

[Helmut Backhaus]

Hallo Marcus!

Am 10.06.2016 um 19:45 schrieb Marcus Roeckrath:
> Hallo Kay,
>
> Kay Martinen wrote:
>
>>> Eines sollte man noch beachten: Was passiert, wenn jemand kurz
>>> hintereinander zwei Sessions aufmacht?
>>
>> Darf ich raten, Race-condition? Oder gilt das nur im Kernel so?
>
> Das Checkskript arbeitet dann erstmal auf der gleichen temporären Datei; das
> später gestartete Skript findet diese dann schon vor und nimmt an, dass der
> Check aktuell ist und gibt ein Ergebnis aus, auch wenn Prozess 1 diese noch
> garnicht komplett mit Daten gefüllt hat.
>
> Prozess 2 kann aber auch so schnell auf Prozess 1 folgen, dass die temporäre
> Datei noch nicht existiert, dann wird list-packages zweimal gestartet.

Wenn ich ehrlich bin, ich komme hier nicht mehr mit! ;-)

>
> Welche Auswirkungen das hat, müsste man in list-packages untersuchen;
> zumindest werden hardcodete Temp-Files genutzt, so dass ein Doppelstart
> nicht anzuraten ist.
>

Das habe ich aus versehen getestet, ich hatte in dem Cronjob einen
Fehler, der dazu führte das alle 4 Std das Script 60 mal gestartet
wurde. Das wurde klaglos ausgeführt, ich hatte 59 Mails pro Stunde! :-))


--
Gruß,
Helmut

[Helmut Backhaus]

Hallo zusammen!

Am 10.06.2016 um 20:47 schrieb Olaf Jaehrling:
> Hi Marcus,
>
> Marcus Roeckrath schrieb am 10.06.2016 um 20:15:
>> Hallo Olaf,
>>
>> Olaf Jaehrling wrote:
>>
>>>> Es ist nicht ausgeschlossen, dass diese Datei durch ein Base-Update
>>>> überschreiben wird.
>>>
>>> Du meinst die /etc/profile?
>>>

Da habt ihr wohl recht! Das war ja aber auch nur mal eben schnell mit
"heißer Nadel" zum testen gestrickt!

>
>>
>> Ok, ich versuche Änderungen an soclhen Standarddateien zu vermeiden.

Ich auch, aber es lässt sich manchmal nicht umgehen!

>
> Jupp, ich auch, aber es gibt Programme, die nur darauf zugreifen, weil
> ebend halt Systemübergreifend. So auch mein UPS-Programm. Daran habe ich
> es ja gemerkt :)
>>
>> Auf Nummer Sicher könnte man bei Benutzung der /root/.profile gehen.
>
> Das gilt dann aber auch nur für root.
>

Trotzdem, das wäre noch eine Idee!


--
Gruß,
Helmut

[Helmut Backhaus]

LOL!!!

Aber mal anders gefragt wo sollte das denn eurer Meinung nach hin?

Ich bin der Meinung, dass sich User eher nie auf so einer Maschine
einloggen. Die Nutzen doch eigentlich nur die Dienste, oder?



--
Gruß,
Helmut

[Marcus Roeckrath]

Hallo Helmut,

Helmut Backhaus wrote:

>> Welche Auswirkungen das hat, müsste man in list-packages untersuchen;
>> zumindest werden hardcodete Temp-Files genutzt, so dass ein Doppelstart
>> nicht anzuraten ist.
>
> Das habe ich aus versehen getestet, ich hatte in dem Cronjob einen
> Fehler, der dazu führte das alle 4 Std das Script 60 mal gestartet
> wurde. Das wurde klaglos ausgeführt, ich hatte 59 Mails pro Stunde! :-))

Hat Dein Server ja ordentlich etwas zu tun gehabt.

Große Probleme scheint also ein paralleler Stat nicht zu machen. :-)

--
Gruss Marcus

[Helmut Backhaus]

Hallo Hilmar!

Am 09.06.2016 um 09:14 schrieb Hilix:
> Am 09.06.2016 um 01:37 schrieb Kay Martinen:
> > Aber zum Update-Problem: es gibt für den Eis, ein Mailpaket, ein
> > ssmtp-Paket u.v.m. ... WARUM gibt es eigentlich immer noch kein
> > "Schick mir eine mail wenn updates da sind"-Paket?
>
> ....das wäre wirklich eine gute Sache!

Deshalb bin ich da ja dran, aber dass es so ausartet ....

>
> Und bevor ich (oder andere User) beginne, mein eigenes "Schick
> mir eine mail wenn updates da sind"-Paket zu basteln (bin kein
> Programmierer),

Bin ich auch nicht, aber Versuch macht klug ... ;-)
Mit jedem eigenem Script wird es besser.

> könnte es doch vonseiten der Distribution bereit
> gestellt werden.
> ssmtp nutze ich bereits, um mir Nachrichten über von clamav gefundene
> Viren schicken zu lassen.

Und da fängt mein Problem an, ich habe msmtp drauf und das Paket liefert
*nur* "sendmail" mit. Auf dieser Basis habe ich nun mein Script
geschrieben. Aber mal sehen, ich werde weiter testen.


--
Gruß,
Helmut

[Holger Bruenjes]

Hallo Helmut

Am 2016-06-12 um 15:15 schrieb Helmut Backhaus:

> Und da fängt mein Problem an, ich habe msmtp drauf und das Paket liefert
> *nur* "sendmail" mit. Auf dieser Basis habe ich nun mein Script
> geschrieben. Aber mal sehen, ich werde weiter testen.

Das ist so nicht ganz richtig, Du kannst die Mail auch direkt an
msmtp uebergeben. Viele Skripte suchen aber nach sendmail, darum
legen die SMTP Programme bei eisfair immer einen sendmail link an
der dann auf das entsprechende executable zeigt. Wenn Du ein Skript
hast, dass laufen soll ohne auf ein spezielles SMTP Programm
angewiesen zu sein, benutzt Du sendmail, das klappt dann immer.

Holger

[Marcus Roeckrath]

Hallo Helmut,

Helmut Backhaus wrote:

>> Und bevor ich (oder andere User) beginne, mein eigenes "Schick
>> mir eine mail wenn updates da sind"-Paket zu basteln (bin kein
>> Programmierer),
>
> Bin ich auch nicht, aber Versuch macht klug ... ;-)

Genauso habe ich vor Urzeiten auch angefangen; und siehe, man lernt dazu.

> Mit jedem eigenem Script wird es besser.

Genau und auch nun lerne ich noch dazu, wie zuletzt die Anregung von
Christoph zum Thema mit Semaphoren arbeiten.

> Und da fängt mein Problem an, ich habe msmtp drauf und das Paket liefert
> *nur* "sendmail" mit. Auf dieser Basis habe ich nun mein Script
> geschrieben. Aber mal sehen, ich werde weiter testen.

Ich verwende eigentlich immer das mail-Binary:

eis # ls -la /bin/mail
lrwxrwxrwx 1 root root 13 Apr 13 21:06 /bin/mail -> /usr/bin/mail
eis # ls -la /usr/bin/mail
-rwxr-xr-x 1 root root 73224 Apr 11 08:00 /usr/bin/mail

Gibts es das bei Dir?

Aufruf:

echo "text für Body" | mail s <subject> <empfänger>

--
Gruss Marcus

[Marcus Roeckrath]

Hallo Helmut,

Holger Bruenjes wrote:

> Das ist so nicht ganz richtig, Du kannst die Mail auch direkt an
> msmtp uebergeben. Viele Skripte suchen aber nach sendmail, darum
> legen die SMTP Programme bei eisfair immer einen sendmail link an
> der dann auf das entsprechende executable zeigt. Wenn Du ein Skript
> hast, dass laufen soll ohne auf ein spezielles SMTP Programm
> angewiesen zu sein, benutzt Du sendmail, das klappt dann immer.

Hier ein Codebeispiel aus dem postgres-Paket:


SENDMAIL='/usr/sbin/sendmail'
full_domain="$(hostname -f)"
. /var/install/include/eistime
{
echo "From: PostgreSQL Agent <root@${full_domain}>"
echo "To: <${POSTGRESQL_BACKUP_NOTIFY}>"
echo "Subject: PostgreSQL database backup service on Server '${HOSTNAME}'"
echo "Mime-Version: 1.0"
echo "X-Mailer: sendmail PostgreSQL on eisfair"
echo "Content-Type: text/plain; charset=us-ascii"
echo "Content-Transfer-Encoding: 8bit"
echo
echo
echo "Dispatched from PostgreSQL Agent on Server '${HOSTNAME}'"
echo "Current Date: ${EISDATE} Time: ${EISTIME}"
echo
cat /tmp/backup-$$.log
} | ${SENDMAIL} ${POSTGRESQL_BACKUP_NOTIFY}

--
Gruss Marcus

[Holger Bruenjes]

Hallo

Am 2016-06-12 um 15:38 schrieb Marcus Roeckrath:

> Hier ein Codebeispiel aus dem postgres-Paket:

das ist im Ursprung von mir und findet sich an vielen Stellen ;-))

Holger

[Helmut Backhaus]

Hallo Holger!

Am 12.06.2016 um 15:29 schrieb Holger Bruenjes:
> Hallo Helmut
>
> Am 2016-06-12 um 15:15 schrieb Helmut Backhaus:
>
>> Und da fängt mein Problem an, ich habe msmtp drauf und das Paket liefert
>> *nur* "sendmail" mit. Auf dieser Basis habe ich nun mein Script
>> geschrieben. Aber mal sehen, ich werde weiter testen.
>
> Das ist so nicht ganz richtig, Du kannst die Mail auch direkt an
> msmtp uebergeben.

Gibt es da irgendwo ein Beispiel?

> Viele Skripte suchen aber nach sendmail, darum

Meis gehört jetzt auch dazu! ;-)

> legen die SMTP Programme bei eisfair immer einen sendmail link an
> der dann auf das entsprechende executable zeigt. Wenn Du ein Skript
> hast, dass laufen soll ohne auf ein spezielles SMTP Programm
> angewiesen zu sein, benutzt Du sendmail, das klappt dann immer.
>

Ok, dann bin ich ja auf dem Richtigen weg, oder?

Danke für die Erklärung!


--
Gruß,
Helmut

[Holger Bruenjes]

Hallo Helmut

Am 2016-06-12 um 15:45 schrieb Helmut Backhaus:

>> Das ist so nicht ganz richtig, Du kannst die Mail auch direkt an
>> msmtp uebergeben.
>
> Gibt es da irgendwo ein Beispiel?

Es passiert ja nichts anderes, ob Du jetzt sendmail oder msmtp
benutzt is egal.

Du kannst einfach sendmail durch msmtp ersetzen, das wars schon.


Wenn es kompatibel sein soll, benutze sendmail, wenn Du es nur
selber benutzen willst auf einer Maschine ist der direkte aufruf von
msmtp auch OK.

Holger

[Helmut Backhaus]

Hallo Marcus!

Am 12.06.2016 um 15:27 schrieb Marcus Roeckrath:
> Hallo Helmut,
>
> Helmut Backhaus wrote:
>
>>> Und bevor ich (oder andere User) beginne, mein eigenes "Schick
>>> mir eine mail wenn updates da sind"-Paket zu basteln (bin kein
>>> Programmierer),
>>
>> Bin ich auch nicht, aber Versuch macht klug ... ;-)
>
> Genauso habe ich vor Urzeiten auch angefangen; und siehe, man lernt dazu.

na ja ein bisschen bin ich beruflich vorbelastet, teletonanlagen kann
ich schon programmieren ... und da gehört auch Unix
Aber das ist eine andere Welt!

>
>> Mit jedem eigenem Script wird es besser.
>
> Genau und auch nun lerne ich noch dazu, wie zuletzt die Anregung von
> Christoph zum Thema mit Semaphoren arbeiten.
>

Ja, das ist 100%tig richtig!
Aber die Geschichte von Christoph ....
Da habe ich die Segel gestrichen, da müsste ich mich erst richtig einlesen.

>> Und da fängt mein Problem an, ich habe msmtp drauf und das Paket liefert
>> *nur* "sendmail" mit. Auf dieser Basis habe ich nun mein Script
>> geschrieben. Aber mal sehen, ich werde weiter testen.
>
> Ich verwende eigentlich immer das mail-Binary:
>
> eis # ls -la /bin/mail
> lrwxrwxrwx 1 root root 13 Apr 13 21:06 /bin/mail -> /usr/bin/mail
> eis # ls -la /usr/bin/mail
> -rwxr-xr-x 1 root root 73224 Apr 11 08:00 /usr/bin/mail
>
> Gibts es das bei Dir?
>

eis1-g1 # which mail
which: no mail in (/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/bin)

> Aufruf:
>
> echo "text für Body" | mail s <subject> <empfänger>
>

Das kannte ich, und habe mich damit auch zuerst versucht. Aber wie...
Deshalb habe ich ja den Trade Minimal mail senden aufgemacht ...

--
Gruß,
Helmut

[Helmut Backhaus]

Hallo Holger!

Ah, das ist ja genau so wie ich es mache, Danke!
Das hatte ich schon aus der Testmail "abgekupfert"


--
Gruß,
Helmut

[Marcus Roeckrath]

Hallo Helmut,

Helmut Backhaus wrote:

> Gibt es da irgendwo ein Beispiel?

Hatte ich eben aus einem Paket von Holger gepostet und müsste inzwischen
verteilt sein.

--
Gruss Marcus

[Marcus Roeckrath]

sendmail ist universeller und das hast Du ja nun im Skript drin.

In meinem mail-addon-certs benutze ich einen ähnlichen
sendmail-Codeschnipsel.

--
Gruss Marcus

[Helmut Backhaus]

Danke Marcus und Holger, so hab ich es ja gemacht nur anderswo gefunden ;-)

Gruß,
Helmut

[Hilmar Böhm]

Hallo,

erstmal vieelen Dank für das Skript! Prima!
Ich habe aber noch ein paar kleine Probleme damit, wobei ich nicht weiß,
ob die u.a. Version die letzte ist (wenn nicht, bitte Info, und sorry):

1. Das Skript zeigt bei mir 1 upgradable package, auch wenn lt "Setup"
keines vorhanden ist.

2. Um das Skript zu testen, habe ich jedes Mal vorher die
"/tmp/update-chk.dat" Datei gelöscht. Das Skript läuft auf meinem System
ca. zweieinhalb Minuten, nach dem Upgrade auf Base 2.7.4 und einem
Reboot waren es sogar gut _vier_einhalb Minuten.

Das ist für einen (kurzen) Check bei Einloggen zu lange. Deshalb würde
ich mir einen Cronjob für diesen Check wünschen. Btw. ich setze (wie
schon gesagt) _s_smtp ein (aus dem EIS-Rep.); das ist auch ein send-only
Mailtransferagent.

Besteht eine Chance für so einen Hintergrundjob.

3. Wenn ich das Skript mit ^C abbreche, ist offensichtlich dennoch die
"/tmp/update-chk.dat"-Datei geschrieben worden. Wenn das System während
der Ausführung des Skripts crasht, wird der nächste Check erst 1 Tag
später ausgeführt.

Grüße. / Hilmar.


Am 09.06.2016 um 23:26 schrieb Helmut Backhaus:
> Hallo Marcus!

>
> Am 09.06.2016 um 22:34 schrieb Marcus Roeckrath:
>> Hallo Helmut,
>>
>> Helmut Backhaus wrote:
>>

>>> Nicht drängeln! :-))
>>
>> Natürlich nicht; es gilt - wie immer - Weihnachten.
>
> Dann müssen wir uns nur noch auf's Jahr einigen ...
>
>>
>>> Ich bin eigentlich fertig, aber da ist noch ein blöder Fehler drin. Ich
>>> bin aber wohl auf dem Richtigen Weg ...
>>
>> Du kannst uns ja am aktuellen Stand teilhaben, um nach dem blöden
>> Fehler zu
>> suchen.
>>
>
> Nur ruhig, ich glaube ich habe fertig!

>
> Das folgende Script habe ich unter unter "/usr/local/bin/update-chk.sh"
> abgelegt und Ausführbar gemacht "chmod +x /usr/local/bin/update-chk.sh".
> Dann habe ich einen Eintrag in die Datei "/etc/profile" in die Zeile 38
> hinter:
>
> if [ ${LOGNAME} = root ]
> then
> --> source /usr/local/bin/update-chk.sh
>
> gemacht!
>

> Damit wird, wenn eine Konsole als root geöffnet wird, dass Script
> gestartet. Eine Ausgabedatei wird in "/tmp/update-chk.dat" abgelegt. Auf
> Basis dieser Datei wird auch geprüft, ob eine Prüfung durchgefüht wird.
> Ich habe den Wert auf einmal am Tag gesetzt "tcheck=$((60*60*24))". Wenn
> gewünscht kann dieser Wert auch auf z.B. "tcheck=$((60*60*24*7)) gesetzt
> werde (eine Woche).
>
> Ich habe mich für diesen Weg entschieden, weil "mail" nicht zu den
> Bordmitteln gehört (oder habe ich da etwas übersehen?). Das Script läuft
> also "out of the box"!
>
> Eine Mail-Variante habe ich auch noch in der Pipeline aber das kann ich
> nicht testen, weil ich keinen Eis 1 mit Mail habe. Das muss ich mir dann
> erst mal installieren.
>
> OK, genug geschwafelt! Hier das Script:
> Bitte mit den Umbrüchen aufpassen!!!
>
> -->
>
> #!/bin/bash
>
> ########################################################################
> # update-chk.sh
> # ein mini Script um auf einem Eisfair 1 beim log in als root zu prüfen
> # ob upgrades für den Server vorliegen.
> # Das Script kann in die Datei "/etc/profile" eingebunden werden um es
> # beim login ausführen zu lassen.
> #
> # Ich habe es in Zeile 38 hinter:
> # if [ ${LOGNAME} = root ]
> # then
> # source /usr/local/bin/update-chk.sh
> # eingebunden!
> # So wird es nur beim Login als root gestartet und das auch nur einmal
> # Täglich.
> #
> # Autor : Helmut Backhaus
> # Erstell am: 09.06.2016
> # Geändert am: 09.06.2016
> # Version : 0.0.1
> ########################################################################
>
> # set -xv
>
> ausgabe()
> {
> sed -i '/WARNING/d' $chkfile
> lastcheck=$(cat $chkfile | grep -i 'last check')
> sed -i '1d' $chkfile
> count=$(cat $chkfile | wc -l)
> if [ $count -gt 0 ] ; then
> /usr/local/bin/colecho "There are $count upgradable packages
> available!" rd
> /usr/local/bin/colecho "For more info run Setup!" rd
> echo
> else
> /usr/local/bin/colecho "There are no upgradable packages
> available!" gn
> /usr/local/bin/colecho "Your System is fine!" gn
> echo
> fi
> }
>
> chkfile="/tmp/update-chk.dat"
> tnow=$(date "+%s")
> tcheck=$((60*60*24))
>
> if ! [ -f $chkfile ] ; then
> /usr/local/bin/colecho "There is no chk file for upgrade check" gn
> /usr/local/bin/colecho "Will be done, please wait ..." gn
> echo
> /var/install/bin/list-packages --batch upgradable > $chkfile
> ausgabe
> checkvar="yes"
> else
> tdatei=$(stat -c %Z $chkfile)
> alter=$(( $tnow - $tdatei ))
> fi
>
> if [ -z $checkvar ] && [ $alter -ge $tcheck ] ; then
> rm $chkfile
> /usr/local/bin/colecho "Upgrade check will be done!" gn
> /usr/local/bin/colecho "Please wait ..." gn
> echo
> /var/install/bin/list-packages --batch upgradable > $chkfile
> ausgabe
> else
> if [ -z $checkvar ] && [ -n $alter ] ; then
> /usr/local/bin/colecho "Updates are allready checked today!" gn
> echo
> fi
> fi
> <--
>
> Wie immer feedback Erwünscht!!
>
>

[Marcus Roeckrath]

Hallo Hilmar,

Hilmar Böhm wrote:

> 1. Das Skript zeigt bei mir 1 upgradable package, auch wenn lt "Setup"
> keines vorhanden ist.

Das Skript zeigt ale Update (stable, testing, unstable) an.

Drück mal im Menu bei den Upgradable Packages die Taste F3. Sind es nun auch
2 Updates?

> 2. Um das Skript zu testen, habe ich jedes Mal vorher die
> "/tmp/update-chk.dat" Datei gelöscht. Das Skript läuft auf meinem System
> ca. zweieinhalb Minuten, nach dem Upgrade auf Base 2.7.4 und einem
> Reboot waren es sogar gut _vier_einhalb Minuten.
>
> Das ist für einen (kurzen) Check bei Einloggen zu lange. Deshalb würde
> ich mir einen Cronjob für diesen Check wünschen. Btw. ich setze (wie
> schon gesagt) _s_smtp ein (aus dem EIS-Rep.); das ist auch ein send-only
> Mailtransferagent.
>
> Besteht eine Chance für so einen Hintergrundjob.

Du hast update.chk01.sh nach Anleitung als cronjob eingetragen oder läßt es
über die /etc/profile beim Login ausführen?

update-chk01.sh ist zur Auführung als cronjob im Hintergrund gedacht,
update-chk02.sh zur Ausführung beim Login.

Letzteres führt keine Prüfung durch, sondern zeigt nur anhand einer
vorhandenen /tmp/update-chk.dat an, ob Updates vorliegen. Wurde der cronjob
noch nicht ausgeführt, gibt es /tmp/update-chk.dat natürlich noch nicht.

> 3. Wenn ich das Skript mit ^C abbreche, ist offensichtlich dennoch die
> "/tmp/update-chk.dat"-Datei geschrieben worden. Wenn das System während
> der Ausführung des Skripts crasht, wird der nächste Check erst 1 Tag
> später ausgeführt.

Wie oft das Skript ausgeführt wird, kannst Du anhand der Definition des
cronjobs selbst festlegen; wie ist das zur Zeit bei Dir definiert.

Eine Updateprüfung einmal am Tag sollte vollkommen ausreichen.

Die aktuellen Fassungen des Skripts werden im Thread

Neuansatz zu Updates prüfen

diskutiert (Downloadlinks ebenso dort).

--
Gruss Marcus

[Helmut Backhaus]

Hallo Hilmar, hallo Marcus!

Am 13.06.2016 um 14:15 schrieb Marcus Roeckrath:
> Hallo Hilmar,
>
> Hilmar Böhm wrote:
>
>> 1. Das Skript zeigt bei mir 1 upgradable package, auch wenn lt "Setup"
>> keines vorhanden ist.
>
> Das Skript zeigt ale Update (stable, testing, unstable) an.
>
> Drück mal im Menu bei den Upgradable Packages die Taste F3. Sind es nun auch
> 2 Updates?

Ich weiß nicht genau welches Script Hilmar verwendet. Ich vermute, dass
es das eine ist, welches falsch gezählt hat. Das hat die "Last Update"
Zeile mit gezählt!

>
>> 2. Um das Skript zu testen, habe ich jedes Mal vorher die
>> "/tmp/update-chk.dat" Datei gelöscht. Das Skript läuft auf meinem System
>> ca. zweieinhalb Minuten, nach dem Upgrade auf Base 2.7.4 und einem
>> Reboot waren es sogar gut _vier_einhalb Minuten.
>>
>> Das ist für einen (kurzen) Check bei Einloggen zu lange. Deshalb würde
>> ich mir einen Cronjob für diesen Check wünschen. Btw. ich setze (wie
>> schon gesagt) _s_smtp ein (aus dem EIS-Rep.); das ist auch ein send-only
>> Mailtransferagent.
>>
>> Besteht eine Chance für so einen Hintergrundjob.
>
> Du hast update.chk01.sh nach Anleitung als cronjob eingetragen oder läßt es
> über die /etc/profile beim Login ausführen?

Hier habe ich nun auch den Vorschlag mit der .profile Datei ausprobiert,
geht wunderbar!

Also im Verzeichnis /root eine Datei anlegen "/root/.profile" mit
folgendem inhalt:
# For Update Checker on login
. /usr/local/bin/update-chk02.sh

>
> update-chk01.sh ist zur Auführung als cronjob im Hintergrund gedacht,
> update-chk02.sh zur Ausführung beim Login.

Hier nochmal die Links zu den Scripten:
http://www.112-ausbildung.org/download/eis/update-chk01.sh
http://www.112-ausbildung.org/download/eis/update-chk02.sh

>
> Letzteres führt keine Prüfung durch, sondern zeigt nur anhand einer
> vorhandenen /tmp/update-chk.dat an, ob Updates vorliegen. Wurde der cronjob
> noch nicht ausgeführt, gibt es /tmp/update-chk.dat natürlich noch nicht.

Wie Markus schon schrieb, hier hat sich dann das gesamte Konzept
geändert. Auch geht es nun die Ergebnisse per Mail zu versenden
und für den Konsolenensatz wird dann nur die Ergebnisdatei von dem *01
Script ausgelesen.

>
>> 3. Wenn ich das Skript mit ^C abbreche, ist offensichtlich dennoch die
>> "/tmp/update-chk.dat"-Datei geschrieben worden. Wenn das System während
>> der Ausführung des Skripts crasht, wird der nächste Check erst 1 Tag
>> später ausgeführt.
>
> Wie oft das Skript ausgeführt wird, kannst Du anhand der Definition des
> cronjobs selbst festlegen; wie ist das zur Zeit bei Dir definiert.
>
> Eine Updateprüfung einmal am Tag sollte vollkommen ausreichen.

Sehe ich auch so!

>
> Die aktuellen Fassungen des Skripts werden im Thread
>
> Neuansatz zu Updates prüfen
>
> diskutiert (Downloadlinks ebenso dort).
>

Richtig, weil wir diesen Trade hier eigentlich gekapert haben, sorry
noch mal.

Aber das ganze ist im Moment noch mit etwas Handarbeit verbunden!
Ich bin dabei aus dem ganzen ein Paket zu bauen, dauert nur etwas. Ist
meine erstes! :-))

Die Oben genannten Scripte funktionieren, es wird sich vielleicht noch
die eine oder andere Kleinigkeit ändern aber vom Grundsatz her wird es
das wohl sein!!


--
Gruß,
Helmut

[Hilmar Böhm]

Vielen Dank, Dir und Marcus für Eure Antworten.
Diesen neuen Thread zum Thema hatte übersehen... :)

Ich hab' die Skripte ausprobiert. Läuft einwandfrei (inkl. Mail mit
ssmtp). Prima Arbeit!
(So hatte ich mir das gewünscht... :-) )

Jetzt muss ich nur noch das 01er-Skript als Cronjob aufsetzen.
("Anleitung" habe ich ich nicht gefunden. Gibt es da was Besonderes zu
beachten?)

Vielen Dank und Grüße. / Hilmar.

[Hilmar Böhm]

noch #ne Frage bitte (die nur indirekt mit dem Thema hier zusammenhängt.):
In der ssmtp.conf steht mein PW für den Mailaccount auf dem Mailserver
im Klartext. Gibt es da eine intelligente/re Methode, es nicht so
offensichtlich zu präsentieren oder es irgendwie zu "verstecken"
Danke und Gruß. / Hilmar.

[Marcus Roeckrath]

Hallo Hilmar,

Hilmar Böhm wrote:

> Jetzt muss ich nur noch das 01er-Skript als Cronjob aufsetzen.
> ("Anleitung" habe ich ich nicht gefunden. Gibt es da was Besonderes zu
> beachten?)

Trage in der cron-Konfiguration einen cronjob ein (System administration
cron administration):

CRON_2_NAME='Update Check'
CRON_2_ACTIVE='yes'
CRON_2_TIMES='15 0 * * *'
CRON_2_COMMAND='/usr/local/bin/update-chk01.sh'

Dann läuft es immer um 0:15 Uhr.

--
Gruss Marcus

[Marcus Roeckrath]

Hallo Hilmar,

Hilmar Böhm wrote:

> noch #ne Frage bitte (die nur indirekt mit dem Thema hier zusammenhängt.):
> In der ssmtp.conf steht mein PW für den Mailaccount auf dem Mailserver
> im Klartext. Gibt es da eine intelligente/re Methode, es nicht so
> offensichtlich zu präsentieren oder es irgendwie zu "verstecken"

Das gilt auch für das Mail-Paket, da stehen in der Konfigurationsdatei auch
die Passwörter drin.

Das geht nicht anders.

Solche Dateien dürfen nur für root lesbar sein. Wie sehen denn die Rechte
der Datei aus?

--
Gruss Marcus

[Juergen Edner]

Hallo Hilmar,

> 1. Das Skript zeigt bei mir 1 upgradable package, auch wenn lt "Setup"
> keines vorhanden ist.
>
> 2. Um das Skript zu testen, habe ich jedes Mal vorher die
> "/tmp/update-chk.dat" Datei gelöscht. Das Skript läuft auf meinem System
> ca. zweieinhalb Minuten, nach dem Upgrade auf Base 2.7.4 und einem
> Reboot waren es sogar gut _vier_einhalb Minuten.

wenn ich Dich recht verstehe möchtest Du automatisch über verfügbare
Paket-Updates informiert werden, korrekt? Ich lasse mich über Nagios
über verfügbare Updates informieren. Umgesetzt habe ich dies wie folgt:

1. Einen Cronjob angelegt, welcher alle zwei Stunden prüft, ob neue
Updates verfügbar sind:

0 */2 * * * /var/install/bin/list-packages --batch --stableonly
--nosvn upgradable > /var/lib/nagios/check_eisfair_updates.list;
if [ $? -eq 0 ]; then chown nagios:nagios /var/lib/nagios
/check_eisfair_updates.list;
chmod 644 /var/lib/nagios/check_eisfair_updates.list; fi

2. Über ein Skript prüfe ich dann ob der Sring "No upgradable-packages
found" in der erzeugten Datei enthalten ist. Falls ja, gibt es keine
Updates, falls nein, sende ich eine Benachrichtigung raus.

Vielleicht hilft Dir ja dieser Ansatz Dein Problem zu lösen.

Gruß Jürgen
--
Mail: jue...@eisfair.org

[Hilmar Böhm]

Danke. Bin ganz begeistert von diesem neuen Dienst! :-)
Grüße.

[Hilmar Böhm]

Hallo Marcus,

Am 14.06.2016 um 08:37 schrieb Marcus Roeckrath:
> Hallo Hilmar,
>
> Hilmar Böhm wrote:
>
>> noch #ne Frage bitte (die nur indirekt mit dem Thema hier zusammenhängt.):
>> In der ssmtp.conf steht mein PW für den Mailaccount auf dem Mailserver
>> im Klartext. Gibt es da eine intelligente/re Methode, es nicht so
>> offensichtlich zu präsentieren oder es irgendwie zu "verstecken"
>
> Das gilt auch für das Mail-Paket, da stehen in der Konfigurationsdatei auch
> die Passwörter drin.
>
> Das geht nicht anders.

Das habe ich mir schon gedacht...
(wenn einer einbricht, hat er meistens schon den schwarzen Hut auf und
dann sowieso alles zu spät. Ich dachte nur, dass man es solchen
Individuen nicht leicht machen sollte an sensible Daten zu kommen...)

>
> Solche Dateien dürfen nur für root lesbar sein. Wie sehen denn die Rechte
> der Datei aus?

Gut, denke ich.
(-rw------- 1 root root 560 Jun 14 01:02 /etc/ssmtp/ssmtp.conf)

Grüße. / Hilmar.

[Hilmar Böhm]

Hallo Jürgen,

vielen Dank für Deinen Tipp. Allerdings ist m.E. Nagios für meine kleine
Umgebung zu Hause doch etwas zu dick :) (Obwohl es sich sicherlich
lohnen würde, sich damit zu beschäftigen; vor allem auch, weil es m.W.
plattformübergreifend ist...)

Ansonsten bin ich mit Helmuts Lösung sehr zufrieden :-)

Grüße. / Hilmar.

[Helmut Backhaus]

Hallo Jürgen!

Am 14.06.2016 um 10:13 schrieb Juergen Edner:

> Hallo Hilmar,
>
>> 1. Das Skript zeigt bei mir 1 upgradable package, auch wenn lt "Setup"
>> keines vorhanden ist.
>>
>> 2. Um das Skript zu testen, habe ich jedes Mal vorher die
>> "/tmp/update-chk.dat" Datei gelöscht. Das Skript läuft auf meinem System
>> ca. zweieinhalb Minuten, nach dem Upgrade auf Base 2.7.4 und einem
>> Reboot waren es sogar gut _vier_einhalb Minuten.

Das ist mit einer "Zwischenversion" der/des Script/e passiert, deshalb
habe ich mein Konzept komplett geändert. Das passiert so nun nicht mehr!

>
> wenn ich Dich recht verstehe möchtest Du automatisch über verfügbare
> Paket-Updates informiert werden, korrekt? Ich lasse mich über Nagios
> über verfügbare Updates informieren. Umgesetzt habe ich dies wie folgt:

Das ist das Ziel der Übung, auf einfache Weise eine Info zu bekommen, ob
Updates anstehen.

>
> 1. Einen Cronjob angelegt, welcher alle zwei Stunden prüft, ob neue
> Updates verfügbar sind:
>
> 0 */2 * * * /var/install/bin/list-packages --batch --stableonly
> --nosvn upgradable > /var/lib/nagios/check_eisfair_updates.list;
> if [ $? -eq 0 ]; then chown nagios:nagios /var/lib/nagios
> /check_eisfair_updates.list;
> chmod 644 /var/lib/nagios/check_eisfair_updates.list; fi

Das hier ist SUPER interessant!

/var/install/bin/list-packages --batch --stableonly --nosvn upgradable

Das bedeutet, ich kann schon beim aufrufen dieses Scripts
Einschränkungen machen. Sind diese Parameter irgendwo dokumentiert?
Gibt es davon noch mehr?
Oder muss ich mich durch das Script wühlen?

>
> 2. Über ein Skript prüfe ich dann ob der Sring "No upgradable-packages
> found" in der erzeugten Datei enthalten ist. Falls ja, gibt es keine
> Updates, falls nein, sende ich eine Benachrichtigung raus.
>

Na ja, das ist ziemlich das gleiche was ich auch mit meinem Script
mache. Nur teile ich eben auch noch mit "alles ist gut".

> Vielleicht hilft Dir ja dieser Ansatz Dein Problem zu lösen.
>

Nun lass mir doch den "Spaß" ich möchte diese Funktion in ein Paket
gießen und bin auch schon dabei. Aber es ist eben mein "erstes Eis
Paket" und da kann es etwas dauern. Die Scripte waren ja schnell fertig,
jetzt kommt die Fleißarbeit. Aber das kennt ihr ja ... ;-)


--
Gruß,
Helmut

[Marcus Roeckrath]

Ja.

--
Gruss Marcus

[Marcus Roeckrath]

Hallo Helmut,

Helmut Backhaus wrote:

> Das hier ist SUPER interessant!
> /var/install/bin/list-packages --batch --stableonly --nosvn upgradable
>
> Das bedeutet, ich kann schon beim aufrufen dieses Scripts
> Einschränkungen machen. Sind diese Parameter irgendwo dokumentiert?
> Gibt es davon noch mehr?
> Oder muss ich mich durch das Script wühlen?

Da sind schon alle möglichen Optionen drin.

--
Gruss Marcus

[Helmut Backhaus]

Hallo Hilmar!

Am 13.06.2016 um 12:40 schrieb Hilmar Böhm:
> Hallo,
>
> erstmal vieelen Dank für das Skript! Prima!
> Ich habe aber noch ein paar kleine Probleme damit, wobei ich nicht weiß,
> ob die u.a. Version die letzte ist (wenn nicht, bitte Info, und sorry):
>
> 1. Das Skript zeigt bei mir 1 upgradable package, auch wenn lt "Setup"
> keines vorhanden ist.
>

So, diesen Fehler habe ich nun selbst gehabt und auch gleich gefunden!
Wenn ich eine Zeile, die darauf hin weißt das keine Updates vorhanden
sind in die Ergebnisdatei schreibe, muss ich sie zum zählen der Einträge
natürlich wieder raus filtern!

Das Problem tritt *nur* auf der Konsole auf!

Entweder, Du wartest auf das Paket oder du kannst Dir die betroffene
Datei "update-chk02.sh" hier herunterladen:
http://112-ausbildung.org/download/eis/update-chk02.sh

Wie Du möchtest ... ;-)


--
Gruß,
Helmut

[Marcus Roeckrath]

Hallo Christoph,

Christoph Schulz wrote:

> Eine funktionierende Möglichkeit unter Linux ist, eine symbolische
> Verknüpfung zu erzeugen, weil das immer atomar ist:
>
> if ! ln -s /tmp/my_skript.$$ /tmp/my_skript.running 2>/dev/null; then
> exit 1
> fi
> [...]
> rm -f /tmp/my_skript.running

Helmut hat folgende Lösung im Internet ausfindig gemacht, die für mich sehr
elegant aussieht:

# Das Skript öffnet sich selbst zum Lesen mit Filedesciptor 9
exec 9<"$0"
# Versuch das exklusiv zu locken
if ! flock -n 9 ; then
exit 1
fi

--
Gruss Marcus