[DPKG] correcte manier package verwijderen(?)

[amx]

Als ik een package verwijder, en de situatie netjes wil achterlaten, ga ik stappen volgen die onverwachte gevolgen kunnen hebben:

code:

root@ubuntu-server:/home/amx# dpkg -l | grep deconz
ii  deconz                                        2.12.06-ubuntu-focal-stable           amd64        A generic ZigBee monitoring and control tool
root@ubuntu-server:/home/amx# apt remove deconz deconz-dev -y
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package 'deconz-dev' is not installed, so not removed
The following packages were automatically installed and are no longer required:
  libqt5serialport5-dev libqt5websockets5 libqt5websockets5-dev
Use 'sudo apt autoremove' to remove them.
dpkg: warning: while removing deconz, directory '/usr/share/deCONZ/plugins' not empty so not removed
dpkg: warning: while removing deconz, directory '/usr/lib/systemd/system' not empty so not removed
Processing triggers for mime-support (3.64ubuntu1) ...
Processing triggers for gnome-menus (3.36.0-1ubuntu1) ...
Processing triggers for desktop-file-utils (0.24-1ubuntu3) ...
root@ubuntu-server:/home/amx# apt autoremove -y
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
  libqt5serialport5-dev libqt5websockets5 libqt5websockets5-dev
0 upgraded, 0 newly installed, 3 to remove and 3 not upgraded.
After this operation, 399 kB disk space will be freed.
(Reading database ... 254056 files and directories currently installed.)
Removing libqt5serialport5-dev:amd64 (5.12.8-0ubuntu1) ...
Removing libqt5websockets5-dev:amd64 (5.12.8-0ubuntu1) ...
Removing libqt5websockets5:amd64 (5.12.8-0ubuntu1) ...
Processing triggers for libc-bin (2.31-0ubuntu9.2) ...
root@ubuntu-server:/home/amx# rm -rf /usr/share/deCONZ/plugins
root@ubuntu-server:/home/amx# rm -rf /usr/lib/systemd/system/ :|

Ik snap wat de gevolgen zijn als ik mijn systeem netjes op wil schonen en blind de stappen volg die door apt worden teruggegeven.DPKG laat me dan weten dat het nog niet helemaal netjes is opgeruimd.

code:

dpkg: warning: while removing deconz, directory '/usr/share/deCONZ/plugins' not empty so not removed
dpkg: warning: while removing deconz, directory '/usr/lib/systemd/system' not empty so not removed

Ik weet dat een Youtuber iets vergelijkbaars heeft ervaren waardoor een nieuwe installatie gebrickt is.

Op zich kon dit wel een mooie examenvraag zijn voor Linux: Wat is het effect van deze commando's, wat zijn de gevolgen, welke problemen lost dit op, en welke problemen kan dit opleveren?

code:

root@ubuntu-server:/home/amx# rm -rf /usr/share/deCONZ/plugins
root@ubuntu-server:/home/amx# rm -rf /usr/lib/systemd/system/

Wat ik me afvraag: is hier een best practice/nette manier voor?

[DaFeliX]

Niet doen; of in elk geval niet blind.

dpkg weet waar een package bestanden naar toe heeft geschreven, en verwijderd deze. Als hij dan de bijbehorende mappen wil weghalen, constateert dpkg dat er nog andere bestanden in staan en breng je daarvan op de hoogte. Wat er dan in die mappen staat, dat is aan de gebruiker om te bepalen of dat weg moet.

Soms zijn het bestanden die inderdaad weg zouden kunnen, denk aan configuratiebestanden van die package, of extra dingen die de applicatie zelf heeft geïnstalleerd (wat /usr/share/deCONZ/plugins zou kunnen zijn). Maar soms schrijft een package bestanden naar een andere plek, zoals naar /usr/lib/systemd/system/; deze wil je niet weghalen omdat je daarmee alle systemd configuratie weghaald, en je systeem zeer waarschijnlijk niet meer zou werken.

Ergo: Altijd even handmatig kijken wat er in die mappen staat, voor je ze weggooit. Bij twijfel, gewoon laten staan; het kan (waarschijnlijk) geen kwaad

[DiedX]

Was —purge niet de flag hierbij? En inderdaad, niet los weggooien.

[amx]

nee snap dat ik het niet moet weggooien inderdaad.

code:

root@ubuntu-server:/home/amx# apt purge deconz
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following package was automatically installed and is no longer required:
  libqt5websockets5
Use 'sudo apt autoremove' to remove it.
The following packages will be REMOVED:
  deconz*
0 upgraded, 0 newly installed, 1 to remove and 13 not upgraded.
After this operation, 39.0 MB disk space will be freed.
Do you want to continue? [Y/n] y
(Reading database ... 255511 files and directories currently installed.)
Removing deconz (2.12.06-ubuntu-focal-stable) ...
dpkg: warning: while removing deconz, directory '/usr/lib/systemd/system' not empty so not removed
Processing triggers for mime-support (3.64ubuntu1) ...
Processing triggers for gnome-menus (3.36.0-1ubuntu1) ...
Processing triggers for desktop-file-utils (0.24-1ubuntu3) ...

zelfde onduidelijkheid. Punt waarom ik het topic heb aangemaakt, is dat dpkg wel zelf de fout vermijdt, maar een onervaren maar wel secuur werkend Linux gebruiker (zij het wel met sudo rechten) dubieuze informatie krijgt.

[edit]

Ergo: Altijd even handmatig kijken wat er in die mappen staat, voor je ze weggooit. Bij twijfel, gewoon laten staan; het kan (waarschijnlijk) geen kwaad

beste antwoord, I guess. Dank!

Niet evenveel discussiewaarde als ik aanvankelijk dacht.

[ Voor 10% gewijzigd door amx op 17-11-2021 08:23 ]

[thunder7]

Het is geen fout, maar een waarschuwing.

Het is niet dubieus, maar gewoon waar.

Zoals DaFelix hierboven schreef

Ergo: Altijd even handmatig kijken wat er in die mappen staat, voor je ze weggooit. Bij twijfel, gewoon laten staan; het kan (waarschijnlijk) geen kwaad

[amx]

Ik had deze achteraf toch beter in de NOS kroeg kunnen plaatsen, maar is een vraag aan gekoppeld naast de (vind ik) wel schetsende werking van Linux en hoe je wordt verwacht te redeneren.

De best practice altijd even handmatig kijken is vind ik wel erg tijdrovend. Dat is juist de reden waarom ik via de command line werk, omdat het vaak sneller werkt.

[edit]

het is op zich gezien dat er een FHS is, best te doen om dpkg meldingen te dempen als de melding het exacte pad: /bin, /sbin, /etc/systemd/system bevat. Ik vind het interessanter om te kijken of dat top-down kan, niet alleen voor dpkg in dat geval

[ Voor 26% gewijzigd door amx op 17-11-2021 08:36 ]

[DaFeliX]

amx schreef op woensdag 17 november 2021 @ 08:13:
[...]

zelfde onduidelijkheid. Punt waarom ik het topic heb aangemaakt, is dat dpkg wel zelf de fout vermijdt, maar een onervaren maar wel secuur werkend Linux gebruiker (zij het wel met sudo rechten) dubieuze informatie krijgt.

[...]

elke Linuxgebruiker met sudo rechten is gevaarlijk . Er staat niets voor niets in de sudo-lecture:

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.

(emphasis mine)

[Morzzz]

/usr/share is een plek waar je nog wel eens wat kleine handelingen moet doen, maar /usr/lib is een directory waar je nooit en te nimmer handmatig aanpassingen zou moeten doen.

/etc/systemd is dan toch de plek voor configuratie die niet meekomt met het package?

Laat je package manager dit in ieder geval zoveel mogelijk voor je oplossen :-)

[amx]

Morzzz schreef op woensdag 17 november 2021 @ 11:02:
/usr/share is een plek waar je nog wel eens wat kleine handelingen moet doen, maar /usr/lib is een directory waar je nooit en te nimmer handmatig aanpassingen zou moeten doen.

Nooit en te nimmer vind ik nogal een boude uitspraak. Zeker als je wel eens met Python versies hebt moeten klooien is die map niet onbekend. En waarom dan niet automatiseren? Daar is sudo dan toch voor?

[Morzzz]

amx schreef op woensdag 17 november 2021 @ 14:36:
[...]


Nooit en te nimmer vind ik nogal een boude uitspraak. Zeker als je wel eens met Python versies hebt moeten klooien is die map niet onbekend. En waarom dan niet automatiseren? Daar is sudo dan toch voor?

Maar ook dan is er toch een package manager in het spel? Ofwel pip, ofwel de native package manager van je distro...

[amx]

Morzzz schreef op woensdag 17 november 2021 @ 16:04:
[...]


Maar ook dan is er toch een package manager in het spel? Ofwel pip, ofwel de native package manager van je distro...

Niet in het voorbeeld dat ik in gedachten had

Ik vond de antwoorden behalve de sudo richtlijn (zij het wat generiek) vooral ingaan op dat het nou eenmaal zo is, dus ben proberen na te gaan waarom die antwoorden zijn zoals ze zijn.

Ik heb daarom via

code:

apt download deconz

de deb file naar /tmp gedownload en de package eens bekeken.

In de package zit een mappenstructuur zonder bestanden /etc/systemd/system/

Het is dus compleet normaal dat dkpg deze tegenkomt en denkt "ik moet hier iets mee"

in de package zitten een paar instructies waarvan me een paar opvielen:

• de binary wordt opgeslagen in /usr/bin maar root is eigenaar (waarom dan niet in /usr/sbin?)
• Het script houdt rekening met user systemd files, vandaar vermoedelijk dat de map is toegevoegd,

Ik ben er ook achter dat de webapp best een interessante feature heeft: de zigbee dongle registreert zich bij de ontwikkelaar, die linkt vervolgens je dongle aan je ip adres. Dat levert de volgende feature op: als je naar de webapp url van de ontwikkeaar gaat, kom je automatisch bij je eigen dongle uit. Ziet er wel mooi uit als je met je telefoon op 4g zit en naar de website gaat krijg je een scherm waar geen apparaten worden gevonden, zet ik mijn WIreguard VPN aan, zie ik mijn dongle ineeens.

Wellicht rechtvaardigt mijn aanvankelijke vraag een review van deze dongle, maar mijn oorspronkelijke vraag: wat is de correcte manier om een dergelijke foutmelding veilig af te handelen moet eigenlijk zijn: die foutmelding had daar niet horen te staan.

[Hero of Time]

Dat je die melding over /usr/lib/systemd/system kreeg, is omdat die map in het package zit. Vervolgens is er een post-install script die dan een symlink maakt naar die map. De pre-remove script dat wordt uitgevoerd als je een package verwijdert ruimt die link dan weer op, maar in de file list die dpkg bij houd wanneer het pakketten installeert staat die map nog als 'komt uit dit package' en wil deze opruimen.

De gedachte van degene die deze package op deze manier heeft gemaakt zal te maken hebben met het niet altijd aanwezig zijn van systemd op een installatie. Je kan er namelijk alsnog voor kiezen om openrc (Gentoo default) of een ander init systeem te gebruiken en dan is het niet gegarandeerd dat de map /usr/lib/systemd/system bestaat. Die meenemen in het package zorgt er dan voor dat het post-install script niet faalt wanneer het de link wil maken.

Nou heb ik zelf ook deconz in gebruik en even gekeken hoe het bij mij zit. Ik heb nog een iets oudere versie draaien, maar de bestanden die het installeert is wel hetzelfde. Daar is de map waar je naar verwijst, /usr/lib/systemd/system leeg en doet het er niets mee. Ik heb er wel een bestand in staan (grafana) en zou dpkg dus weigeren de map weg te gooien. In andere gevallen zou het waarschijnlijk de map alsnog opruimen, want leeg. Deconz heeft z'n eigen unit files in /lib/systemd/system gezet, waar al het andere ook staat.

Resume: die melding zou je niet eens hebben gezien, als je geen andere software zou hebben geïnstalleerd die diezelfde map gebruikt en er iets in heeft gezet. Kijk ik naar mijn eigen installatie, dan zou het verwijderen van /usr/lib/systemd/system ervoor zorgen dat Grafana niet meer start.

[amx]

Hero of Time schreef op vrijdag 19 november 2021 @ 10:58:
Dat je die melding over /usr/lib/systemd/system kreeg, is omdat die map in het package zit. Vervolgens is er een post-install script die dan een symlink maakt naar die map. De pre-remove script dat wordt uitgevoerd als je een package verwijdert ruimt die link dan weer op, maar in de file list die dpkg bij houd wanneer het pakketten installeert staat die map nog als 'komt uit dit package' en wil deze opruimen.

klopt, echter heeft deze package geen pre-remove of post-remove scripts of ik heb verkeerd gekeken. Ik zat sowieso om de een of andere reden te zoeken in /etc/systemd/system omdat ik daar nogmaal de meeste systemd wijzigingen doe.

De gedachte van degene die deze package op deze manier heeft gemaakt zal te maken hebben met het niet altijd aanwezig zijn van systemd op een installatie. Je kan er namelijk alsnog voor kiezen om openrc (Gentoo default) of een ander init systeem te gebruiken en dan is het niet gegarandeerd dat de map /usr/lib/systemd/system bestaat. Die meenemen in het package zorgt er dan voor dat het post-install script niet faalt wanneer het de link wil maken.

Dat moet het haast wel zijn, al linkt de ontwikkelaar in de post-install /etc/systemd/system aan handmatig aangemaakte systemd files. Het enige wat mij als eindgebruiker opvalt, is de waarschuwing van dkpg die zegt dat er iets niet helemaal verwijderd is.

Nou heb ik zelf ook deconz in gebruik en even gekeken hoe het bij mij zit. Ik heb nog een iets oudere versie draaien, maar de bestanden die het installeert is wel hetzelfde. Daar is de map waar je naar verwijst, /usr/lib/systemd/system leeg en doet het er niets mee. Ik heb er wel een bestand in staan (grafana) en zou dpkg dus weigeren de map weg te gooien. In andere gevallen zou het waarschijnlijk de map alsnog opruimen, want leeg. Deconz heeft z'n eigen unit files in /lib/systemd/system gezet, waar al het andere ook staat.

Ik heb ook een oudere versie draaien want de systemd service uit de package in de focal repo wil helemaal niet starten

Resume: die melding zou je niet eens hebben gezien, als je geen andere software zou hebben geïnstalleerd die diezelfde map gebruikt en er iets in heeft gezet. Kijk ik naar mijn eigen installatie, dan zou het verwijderen van /usr/lib/systemd/system ervoor zorgen dat Grafana niet meer start.

code:

root@ubuntu-server:/home/amx# ls -la /lib
lrwxrwxrwx 1 root root 7 Apr 23  2020 /lib -> usr/lib

Bij mij is /lib gesymlinked naar /usr/lib. Als ik die map verwijder, ben ik wel degelijk mijn installatie om zeep aan het helpen.

Waarom deconz lokaal draait en niet in een LXD container of in Docker, is weer omdat ik USB forwarding niet helemaal vertrouw/kan inschatten, al is de gehele voorafgaande duscussie wel weer een mooi voorbeeld waarom een container in dit geval een veiligere oplossing is.

[Hero of Time]

Het stukje over post-install en pre-remove scripts schreef ik voordat ik naar het package zelf keek en was meer als een algemene uitleg bedoelt dan specifiek voor deconz.

Ik draai Raspbian Buster, geen Ubuntu variant en bij mij zijn /lib en /usr/lib nog apart (even als /bin, /sbin en /usr/bin en /usr/sbin). Persoonlijk heb ik ook geen behoefte aan containers, omdat ik helemaal geen zin heb om onderlinge communicatie te regelen voor iets wat nog wat extra overhead geeft ook. Plus, geen flauw idee hoe ik de raspbee module zou moeten doorsturen en ook geen zin in om dat uit te zoeken. Containers zijn voor mij meer black holes, geen idee wat degene die het image heeft gemaakt er nog meer in heeft gestopt en debuggen van je software erin is ook wat lastiger.

[DaFeliX]

amx schreef op vrijdag 19 november 2021 @ 07:58:
[...]

• de binary wordt opgeslagen in /usr/bin maar root is eigenaar (waarom dan niet in /usr/sbin?)
• [...]

[...]

Alleereerst is het vermeldingswaardig dat niet elke distro dezelfde regels hanteert omtrend directories naming conventies; en sommige conventies zijn ook gebaseerd op verouderde problemen.

Nu, volgens mij hanteert Ubuntu /usr/sbin voor "systeem" binaries. Hier zou ik wel binaries verwachten zpals bijv. vpn, chroot, fsck en dergelijke. Ik zou hier geen binary verwachten zoals een browser of deCONZ. Wie dan de eigenaar van de binary is, is irrelevant; want in /usr/bin zijn is root de eigenaar van (bijna) alle binaries.