[42_AptToDate.pm] Übersicht über verfügbare Distributionsupdates

[mrbreil]

Hallo CoolTux wieder mal ein super nützliches Modul. Könntest du vielleicht auch eine Unterstützung für YUM einbauen?

Gruß Christian

[CoolTux]

Hallo CoolTux wieder mal ein super nützliches Modul. Könntest du vielleicht auch eine Unterstützung für YUM einbauen?

Gruß Christian

Hallo Christian,

Sieht nicht so gut aus. Ich habe da nichts zum testen. Benutze zwar noch Suse also auch rpm aber die haben ja zypper als client frontend. Sorry


Grüße

[mrbreil]

Schade. Trotzdem Danke für deine schnelle Antwort.

[the ratman]

ich hätt da auch wieder mal ne dumme zwischenfrage:

was würde passieren wenn ein (per aptToDate) zu prüfendes rotes obst selten im netz ist?
gibt das wieder so 10 mio. warnings, wenn mein raspi ned erreichbar ist, oder muß ich mir da keine sorgen machen?

hintergund (bevor wieder komische fragen von der seite einschlagen *g*):
bei dem erfragten pi handelt sichs um einen reinen hifi-player, der eben nur im netz steht wenn ich nicht musik, sondern selbige in besonders guter qualität und in ruhe hören will. also eher alle paar wochen mal. da hats wenig sinn, den durchlaufen zu lassen.[/size

[CoolTux]

ich hätt da auch wieder mal ne dumme zwischenfrage:

was würde passieren wenn ein (per aptToDate) zu prüfendes rotes obst selten im netz ist?
gibt das wieder so 10 mio. warnings, wenn mein raspi ned erreichbar ist, oder muß ich mir da keine sorgen machen?

hintergund (bevor wieder komische fragen von der seite einschlagen *g*):
bei dem erfragten pi handelt sichs um einen reinen hifi-player, der eben nur im netz steht wenn ich nicht musik, sondern selbige in besonders guter qualität und in ruhe hören will. also eher alle paar wochen mal. da hats wenig sinn, den durchlaufen zu lassen.[/size

Du bekommst eine Fehlermeldung als Status

[the ratman]

na wenns nur eine is und ned alle paar minuten immer wieder eine, bin ich schon glücklich. auch wenn ich generell ned versteh, warum mal solcherlei infos ins log werfen muß *g*.

thx für die (wie immer) flotte antwort!

[CoolTux]

na wenns nur eine is und ned alle paar minuten immer wieder eine, bin ich schon glücklich. auch wenn ich generell ned versteh, warum mal solcherlei infos ins log werfen muß *g*.

thx für die (wie immer) flotte antwort!

Im Log kommt nichts. Nur im state Reading

[the ratman]

ahh, na dann hatt ich dich nur miß(t)verstanden *g*

[the ratman]

ich wussts, dass ich das wieder nicht hinbekomm - magst mir kurz helfen, auch wenns eigentlich nix mit aptToDate zu tun hat?
ich trau mich wetten, dass is wieder nur so eine kleinigkeit, die ich im netz grad ned find, weil ich falsch such *g*

was bisher geschah:
o) user fhem auf dem entfernten rechner angelegt. irgendwie schaff ichs aber nicht, dem KEIN passwort zu geben - liegts daran? ich hab ihm mal sicherheitshalber auch in die gruppte tty gelegt.
o) user fhem darf per teminal (von meinem win-rechner aus) am entfernten rechner zumindest schon mal sudo ohne passwort - das geht und er darf dort auch apt-get mit allem drum und dran fahren.
o) aptToDate-device auf fhem angelegt, verbindet auch, kriegt aber einen fetch-error ...

Code Auswählen Erweitern

Internals:
   CFGFN     
   DEF        192.168.178.197
   HOST       192.168.178.197
   NAME       up2date_ratomat
   NOTIFYDEV  global,up2date_ratomat
   NR         8273
   NTFY_ORDER 50-up2date_ratomat
   STATE      system is up to date
   TYPE       AptToDate
   VERSION    1.4.2
   READINGS:
     2019-01-08 12:11:37   os-release_language en
     2019-01-08 12:24:18   repoSync        fetched error
     2019-01-08 12:24:18   state           system is up to date
     2019-01-08 12:17:07   upgradeListAsJSON {}
   helper:
     lastSync   2019-01-08
Attributes:
   alias      ratOmat
   cmdIcon    repoSync:edit_settings
   devStateIcon system.updates.available:system_backup@red:toUpgrade
system.is.up.to.date:system_backup@green:repoSync
.*in.progress:system_backup@orange
   distupgrade 1
   group      updates
   icon       system_backup
   room       computer
   upgradeListReading 1

NACHTRAG
gut, neues: wenn ich das richtig seh, muß ich wohl in richtung ssh was machen. es reicht wohl ned, wenn ich per ssh-keygen einfach kein pwd vergeb?
wenn ich das richtig versteh, muß ich also auf fhem-seite (auf dem rechner mit fhem drauf) dem user fhem einen key ohne pwd verpassen, ein dir ".ssh" suchen (wo auch immer das is), das dir in /opt/fhem kopieren und davon wieder irgendwas auf den andern rechner in ein userverzeichnis kopieren, das dort gar ned existiert.

kann man mir das bitte wer in klicki-bunit-dialekt beibringen? vor allem, wies geht und des weiteren, welche auswirkungen das auf den weiteren fhem-betrieb haben kann?

[CoolTux]

Juhu,

Leider habe ich aktuell keine Luft für das Problem. Wäre schön wenn ein anderer User dem ratman bitte einmal unter die Arme greifen könnte.


Grüße

[MadMax-FHEM]

@Leon: kümmere du dich um's Wetter, ich versuch's mal



@ratman: Also von Windows aus weiß ich nicht, ich kann dir erläutern (versuchen) wie es von Linux auf Linux geht...

o) user fhem auf dem entfernten rechner angelegt. irgendwie schaff ichs aber nicht, dem KEIN passwort zu geben - liegts daran? ich hab ihm mal sicherheitshalber auch in die gruppte tty gelegt.

WOZU das!?
Du brauchst einen User auf dem System, wo du apt-get abfragen willst.
Nennen wir ihn remoteUser.
Dieser muss auf seinem (remote System) OHNE Passwort sudo dürfen!
Also dort (remote Rechner, nennen wir ihn remoteHost   ) musst du für den User "remoteUser" in die sudoers (vorher prüfen ob sudoers installiert ist) einen Eintrag machen.
(je nach System wird direkt die vorhandene sudoers bearbeitet/erweitert [immer neue Einträge ans Ende] oder seit Stretch gibt es unter /etc/sudoers.d/ extra Dateien für Erweiterungen. Beim PI 010_pi_nopasswd oder so ähnlich)


Dann musst du einen ssh-Key für den User fhem erzeugen (oder einen auf dem fhem-Rechner erzeugten nach /opt/fhem/.ssh bzw. das Home des Users fhem und dort dann unter ./ssh kopieren)

Dann per copysshkey diesen auf den anderen Rechner transferieren, damit wenn immer sich User fhem bei remoteHost als remoteUser einloggen will das OHNE Passwortabfrage gelingt, da ja vertrauenswürdige Zertifikate/ssh-Keys vorhanden sind: Passwort unnötig...

Da dann der User fhem auf dem remoteHost als remoteUser agiert und dieser dort "sudo apt-get" ohne Passwort darf sollte es funktionieren...

Hier noch ein Link bzgl. remote: http://heinz-otto.blogspot.com/2017/01/per-ssh-remote-befehle-direkt-ausfuhren.html
Anhang eine Skizze die hoffentlich hilft.

EDIT: in der Skizze ist ein kleiner Fehler:  !sudo service doorpi status" muss nat. "sudo service doorpi status" heißen. Also User fhem auf PI_A loggt sich als User pi (des remoteHost, hier bei uns also remoteUser) auf PI_B ein, dieser (also NICHT fhem von PI_A sondern pi/remoteUser von PI_B führt dann auf "seinem" System PI_B den in Anführungszeichen geschriebenen Befehl aus:  "sudo service doorpi status" bei dir hier eben "sudo apt-get ...". Damit dabei ebenfalls keine Passwortabfrage kommt muss eben remoteUser diese Abfrage auf SEINEM System PI_B OHNE Passwort möglich sein -> sudoers Eintrag)

o) user fhem darf per teminal (von meinem win-rechner aus) am entfernten rechner zumindest schon mal sudo ohne passwort - das geht und er darf dort auch apt-get mit allem drum und dran fahren.

Verstehe ich so nicht.
Weil wenn das ginge, dann würde es funktionieren...


Bitte mal genau erläutern von welchem Rechner (HW/OS/...) du auf welchem Rechner (HW/OS/...) du das apt-get ausführen willst.

Beispiel:

Rechner A: PI3, Raspbian Stretch, fhem

Rechner B: PI2, Raspbian Jessie, kein fhem

Vorhaben: in fhem auf Rechner A das Modul apt-get nutzen um bei Rechner B abzufragen/prüfen

o) aptToDate-device auf fhem angelegt, verbindet auch, kriegt aber einen fetch-error ...

Ein genaue Fehlermeldung wäre hilfreich...
...fhem Log? Evtl. verbose hochdrehen...

Code Auswählen Erweitern

Internals:
   CFGFN     
   DEF        192.168.178.197
   HOST       192.168.178.197
   NAME       up2date_ratomat
   NOTIFYDEV  global,up2date_ratomat
   NR         8273
   NTFY_ORDER 50-up2date_ratomat
   STATE      system is up to date
   TYPE       AptToDate
   VERSION    1.4.2
   READINGS:
     2019-01-08 12:11:37   os-release_language en
     2019-01-08 12:24:18   repoSync        fetched error
     2019-01-08 12:24:18   state           system is up to date
     2019-01-08 12:17:07   upgradeListAsJSON {}
   helper:
     lastSync   2019-01-08
Attributes:
   alias      ratOmat
   cmdIcon    repoSync:edit_settings
   devStateIcon system.updates.available:system_backup@red:toUpgrade
system.is.up.to.date:system_backup@green:repoSync
.*in.progress:system_backup@orange
   distupgrade 1
   group      updates
   icon       system_backup
   room       computer
   upgradeListReading 1

Woher weiß das Modul, dass die Abfrage remote erfolgen soll?
Bin nicht so tief drin in dem Modul...

EDIT2: wenn das hier nicht hilft, dann wohl besser einen neuen Thread mit passendem Titel öffnen. Oder auch mal im Forum suchen, das Thema "remote login etc." wurde (in den letzten Tagen/Wochen) schon so oft behandelt...

Gruß, Joachim

[MadMax-FHEM]

So, habe das PDF noch mal überarbeitet...

War wohl beim "Drucken als PDF" schief gegangen wegen "deutschen Anführungszeichen" und "englischen" (also "oben" vs. "unten")...

Sorry, Joachim

[the ratman]

uij, da gehts ja rund *g* thx für die riesen antwort!

glei mal generelle infos:
o) ich hab fhem auf einem virtuellen debian unter win laufen
o) weiters hab ich einen raspi (mein hifi-gerät), dass aus fhem weg upgedatet werden soll
o) mein verständnis von linux liegt bei: "es hat nen pinguin als logo" = verstehen tu ich sowieso nix, aber abschreiben kann ich ganz gut.

1) ein extra user am raspi heißt nur "fhem" wurde am raspi angelegt und darf lokal am raspiall all das, was er dürfen soll, auch sudo ohne pwd und damit dann apt-get
2) beide rechner wurden einmal mit dem user "fhem" per ssh im terminal von fhem richtung raspi verbunden - sie kennen sich also untereinander - leider aber eben nur nach einer passworteingabe.
3) scheitern tuts am ssh-key, weil ich
3.1) nicht weiß, was mit dem rest meines fhem-systems passieren wird, wenn da auf einmal fhem einen ssh-key hat und ich mich nicht versehentlich irgendwo aussperren will
3.2) ich nicht weiß, wo das verzeichnis .ssh auf debian zu finden is (mal schaun, vielleicht find ich da ja was unter deinem link)
3.3) ich nicht weiß, wo genau ich den key am raspi hinspielen soll. mir wurde kein userverzeichnis "fhem" angelegt, wo ich das nach gefühl hingespielt hätte feh ich als "fhem" auf den raspi, m



ich denk aber mal, ich muß damit eh nomal ganz neu anfangen.
nach einem reboot des raspi komm ich jetzt nicht mehr als user fhem drauf

Code Auswählen Erweitern

login as: fhem
fhem@ratomat's password:
Access denied
egal, ob ohne oder mit passwort. das ging aber schon mal. ich krieg grad die kriese ... werd das mal am we in ruhe angehen

[MadMax-FHEM]

Zum Kopieren des public Keys auf den PI das Programm "ssh-copy-id" verwenden.

Also auf dem fhem-System (Debian VM) als User fhem einloggen.
Dann ssh-Keys erzeugen (ssh-keygen) ohne ein Passwort anzugeben.

Dann mittels genanntem Programm den public Key kopieren, siehe auch: https://www.ssh.com/ssh/copy-id

Wenn du die User entsprechend wie du schreibst eingerichtet hast, dann einfach so:

Code Auswählen Erweitern

ssh-copy-id -i ~/.ssh/id_rsa.pub fhem@IP-des-PI

vorher noch mal prüfen wie die Keys tatsächlich heißen:

Code Auswählen Erweitern

ls -la ~/.ssh

Wichtig (als Windows-Nutzer bzw. Nicht-Linux-Kenner ):
nur weil der User gleich heißt ist es noch lange nicht DERSELBE User!
weil es ist immer User@Host (sofern nicht gegen einen Authentifizierungs-Server geprüft wird und selbst dann: User@Domain   )
und zweitens ist der Name nur für "Menschen", das OS arbeitet mit IDs...
gleiches gilt für Gruppen...

Das reine Anlegen auf dem fhem-Rechner ändert erst mal gar nichts.
Sie werden ja nur verwendet, wenn du ssh nutzt (wie du ja willst/musst).

Wenn auf dem remoteSystem halt falsche Schlüssel liegen, kommst du halt von dem Rechner (fhem, also wo du die Keys angelegt hast) nicht mehr auf das remote-System (wo eben die falschen Keys kopiert wurden).
Ob dann ein "fallback" auf Passwort erfolgt weiß ich nicht...

EDIT: schlimmstenfalls halt alle Schlüssel wieder löschen, was ja funktionieren sollte sofern du dich überhaupt noch auf den Systemen einloggen kannst (bzw. bei einem PI einfach die Karte raus und mit einem anderen Linux-System [live-boot geht auch] bearbeiten).

EDIT2: wenn du (auf Dauer/lange Sicht) mit fhem glücklich werden willst, solltest du dich mit Linux beschäftigen und nicht nur auf Fragen irgendwelche Befehle "abhampeln"...

Gruß, Joachim

[the ratman]

vielen thx - denke, dass krieg ich so hin ... is übrigens angenehm noob-like geschrieben - dafür auch noch n extra danke!