Re: Om debian på desktoppen

Flemming Bjerke <[email protected]> Tue, 7 May 2024 10:38:54 +0200
Newsgroups gmane.linux.debian.user.danish
Message-ID <[email protected]>
This is a multi-part message in MIME format.
--------------A0CXRZ2gthScJamFGF8oVaH9
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Den 06.05.2024 kl. 15.18 skrev Povl Ole Haarlev Olsen:
> On Mon, 6 May 2024, Flemming Bjerke wrote:
>> Jeg har adskillige gange opgivet debian på desktoppen fordi jeg 
>> ustandselig fik problemer med alt muligt der ikke rigtig virkede, 
>> bl.a. programmer som ikke fungerede og ikke kunne opdateres pga. 
>> debians restriktioner på hvornår programmer kunne blive stable. (Jeg 
>> har dog ikke prøvet bookworm af.) Jeg har så valgt at køre med 
>> kubuntu i årevis.
>
> Har du prøvet Debian backports?

Fordi jeg ikke orker at styre det:

> It is recommended to pick out single backports which fit your needs, 
> and not to use all backports available. 
https://wiki.debian.org/Backports


>
> "dia" er, så vidt jeg kan se, ikke i backports, men måske kunne det 
> bruges med nogle af de andre programmer, hvor du ønsker en nyere version.
>
>> Jeg er meget tilfreds med at køre et debian system (sources er 
>> primært debian stable), for jeg har normalt ikke brug for de nyeste 
>> versioner af forskelligt software. Derimod er stabiliteten vigtig for 
>> mig. Men ind i mellem får man brug for en nyere version af et 
>> program. F.eks. er bookworm's version af  dia håbløst buggy. Så fandt 
>> jeg på at chroot til min kubuntu som ligger (passivt)
>
> Hvordan ved du, at bookworms dia er buggy, hvis du ikke har prøvet 
> bookworm?

Nyeste Q2OS er baseret på bookworm med nogle systemændringer.

ls /etc/apt/sources.list.d/
10_q4os.list  20_debian.list  30_debian_backports.list
(backports er ikke aktiveret)

....
>> chroot /a2 mount /dev/sda4 /home
>
> Hvad er grunden til, at du ikke bind-mounter /home?

Det er vel også det rigtigste at bruge bind. Men gør det nogen forskel?


>
>> chroot /a2  #Her kan man udføre alle mulige kommandoer. Skriptet 
>> venter til man kører: exit.
>> #chroot --userspec=flem:flem /a2 (fungerer ikke - forstår ikke hvorfor)
>
> Hmm, hvorfor har jeg ikke hørt om --userspec før?!

man chroot


>
> Hvilken fejlbesked får du?

chroot --userspec=flem:flem /a2
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

bash: /root/.bashrc: Adgang nægtet

Som det fremgår, virker det ikke som at bruge: "su bruger" idet man ikke 
får adgang til det brugeren normalt har adgang til. Så uanset man er 
bruger (og altså ikke root), kan man f.eks. ikke køre dia:

------------

flem@baren:/$ whoami
flem
flem@baren:/$ dia

** (dia:102168): CRITICAL **: 08:48:13.495: Could not create per-user 
Dia configuration directory
----------

På nettet fandt Jeg en måde at omgå dette på:

bash -c "HOME=<jailed home> chroot --userspec=<user>:<group> 
<chroottarget> /bin/bash -i"

Og nu kan mit skript forenkles ganske meget:

#!/bin/bash
mount --bind /home /a2/home
bash -c "HOME=/home/flem chroot --userspec=flem:flem /a2 $1"
umount /a2/home

Med dette skript kan jeg afvikle et program på min ubuntu-partition. F.eks.

./chroot-program.sh dia

Og hvis man ikke angiver et program, startes en kommandoprompt. 
Overordentlig nyttigt.

Det virker ikke som om man behøver mount --bind /sys osv. Faktisk fik 
jeg lidt problemer når jeg gjorde det fordi alt i /dev/pts/ forsvandt. 
Hvorfor fatter jeg ikke, men det har nok noget at gøre med:

> While ‘chroot’ is a powerful tool, it’s not a security measure by 
> itself. Processes that are running as root can break out of the chroot 
> jail. 
https://hopeness.medium.com/master-the-linux-chroot-command-a-comprehensive-guide-f2026f913726 


Men jeg skal nok ikke opdatere kubuntu via chroot ... Risikerer jeg ikke 
at der kommer ged i kernen og boot ... osv.?


> ........
>>
>> Nu kan jeg starte f.eks. kubuntus dia (og libreoffice) fra en 
>> terminal, og hvis jeg gør det med et & efter, fungerer fungerer 
>> programmet videre selv efter exit fra chroot.
>>
>> Hvad synes I om min løsning?
>
> Jeg har haft noget i samme stil (med /home bind-mounted) for at kunne 
> bruge en ældre version af bl.a. xpra.
>
> Jeg havde alle mine bind-mounts i /etc/fstab og en desktop launcher, 
> der "run in terminal" kørte
>
> su -c "chroot /opt/wheezy /bin/su - stderr -c /usr/bin/xfce4-terminal 
> & bg"
>
> (Med --userspec ville den linie sikkert kunne skæres kraftigt ned.)
>
> Launcher'en startede en terminal og alt startet i den terminal blev 
> kørte fra en wheezy installation, jeg havde debootstrap'et i /opt/wheezy.
>
> Det virkede fint til mit formål.

Sejt!

>
>> Det er selvfølgelig ikke uproblematisk at køre to forskellige 
>> systemer på samme home-partition, men hvis man ikke bruger samme 
>> programmer på dem, burde det vel ikke skabe de store problemer?
>
> Hvis programmer opførte sig nogenlunde pænt, ville det heller ikke 
> være noget problem, at køre de samme programmer på samme homedir.
>
> Da jeg var studerende var vores homedirs mountet på Linux, HP-UX, 
> IRIX, Solaris, ... og jeg tænkte ikke ret meget over, om jeg kunne 
> tillade mig, at starte et program på en given platform eller ej.
>
> Men jeg ved godt, at der er nogle programmer, der meget gerne vil lave 
> en "upgrade" af deres config i ~/.config uden at tænke over, at man 
> måske deler sit homedir mellem mange forskellige installationer. Det 
> er eet af problemer ved, at nogen ikke længere ser Linux som et 
> multi-user system i UNIX-familien.

Tak!

Flemming


-- 
Flemming TH Bjerke Tlf. 22120366
--------------A0CXRZ2gthScJamFGF8oVaH9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">Den 06.05.2024 kl. 15.18 skrev Povl Ole
      Haarlev Olsen:<br>
    </div>
    <blockquote type="cite"
cite="mid:alpine.DEB.2.00.2405061420250.25206@noget.server.internal.stderr.dk">On
      Mon, 6 May 2024, Flemming Bjerke wrote:
      <br>
      <blockquote type="cite">Jeg har adskillige gange opgivet debian på
        desktoppen fordi jeg ustandselig fik problemer med alt muligt
        der ikke rigtig virkede, bl.a. programmer som ikke fungerede og
        ikke kunne opdateres pga. debians restriktioner på hvornår
        programmer kunne blive stable. (Jeg har dog ikke prøvet bookworm
        af.) Jeg har så valgt at køre med kubuntu i årevis.
        <br>
      </blockquote>
      <br>
      Har du prøvet Debian backports?
      <br>
    </blockquote>
    <p>Fordi jeg ikke orker at styre det:</p>
    <p>
      <blockquote type="cite">It is recommended to pick out single
        backports which fit your needs, and not to use all backports
        available. </blockquote>
      <a class="moz-txt-link-freetext" href="https://wiki.debian.org/Backports">https://wiki.debian.org/Backports</a><br>
    </p>
    <p><br>
    </p>
    <blockquote type="cite"
cite="mid:alpine.DEB.2.00.2405061420250.25206@noget.server.internal.stderr.dk">
      <br>
      "dia" er, så vidt jeg kan se, ikke i backports, men måske kunne
      det bruges med nogle af de andre programmer, hvor du ønsker en
      nyere version.
      <br>
      <br>
      <blockquote type="cite">Jeg er meget tilfreds med at køre et
        debian system (sources er primært debian stable), for jeg har
        normalt ikke brug for de nyeste versioner af forskelligt
        software. Derimod er stabiliteten vigtig for mig. Men ind i
        mellem får man brug for en nyere version af et program. F.eks.
        er bookworm's version af  dia håbløst buggy. Så fandt jeg på at
        chroot til min kubuntu som ligger (passivt)
        <br>
      </blockquote>
      <br>
      Hvordan ved du, at bookworms dia er buggy, hvis du ikke har prøvet
      bookworm?<br>
    </blockquote>
    <p>Nyeste Q2OS er baseret på bookworm med nogle systemændringer.</p>
    <p>ls /etc/apt/sources.list.d/<br>
      10_q4os.list  20_debian.list  30_debian_backports.list<br>
      (backports er ikke aktiveret)<br>
    </p>
    ....<br>
    <blockquote type="cite"
cite="mid:alpine.DEB.2.00.2405061420250.25206@noget.server.internal.stderr.dk">
      <blockquote type="cite">chroot /a2 mount /dev/sda4 /home
        <br>
      </blockquote>
      <br>
      Hvad er grunden til, at du ikke bind-mounter /home?
      <br>
    </blockquote>
    <p>Det er vel også det rigtigste at bruge bind. Men gør det nogen
      forskel?<br>
    </p>
    <p><br>
    </p>
    <blockquote type="cite"
cite="mid:alpine.DEB.2.00.2405061420250.25206@noget.server.internal.stderr.dk">
      <br>
      <blockquote type="cite">chroot /a2  #Her kan man udføre alle
        mulige kommandoer. Skriptet venter til man kører: exit.
        <br>
        #chroot --userspec=flem:flem /a2 (fungerer ikke - forstår ikke
        hvorfor)
        <br>
      </blockquote>
      <br>
      Hmm, hvorfor har jeg ikke hørt om --userspec før?!
      <br>
    </blockquote>
    <p>man chroot</p>
    <p><br>
    </p>
    <blockquote type="cite"
cite="mid:alpine.DEB.2.00.2405061420250.25206@noget.server.internal.stderr.dk">
      <br>
      Hvilken fejlbesked får du?
      <br>
    </blockquote>
    <p><span style="font-family:monospace">chroot --userspec=flem:flem
        /a2<br>
        To run a command as administrator (user "root"), use "sudo
        &lt;command&gt;".<br>
        See "man sudo_root" for details.<br>
        <br>
        bash: /root/.bashrc: Adgang nægtet<br>
        <br>
      </span></p>
    <p>Som det fremgår, virker det ikke som at bruge: "su bruger" idet
      man ikke får adgang til det brugeren normalt har adgang til. Så
      uanset man er bruger (og altså ikke root), kan man f.eks. ikke
      køre dia:<br>
    </p>
    <p>------------<br>
    </p>
    <p>flem@baren:/$ whoami<br>
      flem<br>
      flem@baren:/$ dia <br>
      <br>
      ** (dia:102168): CRITICAL **: 08:48:13.495: Could not create
      per-user Dia configuration directory<br>
      ----------<br>
    </p>
    <p>På nettet fandt Jeg en måde at omgå dette på:<br>
    </p>
    <p>bash -c "HOME=&lt;jailed home&gt; chroot
      --userspec=&lt;user&gt;:&lt;group&gt; &lt;chroottarget&gt;
      /bin/bash -i"<br>
    </p>
    <p>Og nu kan mit skript forenkles ganske meget:</p>
    <p>#!/bin/bash<br>
      mount --bind /home /a2/home<br>
      bash -c "HOME=/home/flem chroot --userspec=flem:flem /a2 $1"<br>
      umount /a2/home<br>
    </p>
    <p>Med dette skript kan jeg afvikle et program på min
      ubuntu-partition. F.eks.<br>
    </p>
    <p>./chroot-program.sh dia</p>
    <p>Og hvis man ikke angiver et program, startes en kommandoprompt.
      Overordentlig nyttigt. <br>
    </p>
    <p>Det virker ikke som om man behøver mount --bind /sys osv. Faktisk
      fik jeg lidt problemer når jeg gjorde det fordi alt i /dev/pts/
      forsvandt. Hvorfor fatter jeg ikke, men det har nok noget at gøre
      med:</p>
    <p> </p>
    <blockquote type="cite">While ‘chroot’ is a powerful tool, it’s not
      a security measure by itself. Processes that are running as root
      can break out of the chroot jail. </blockquote>
<a class="moz-txt-link-freetext" href="https://hopeness.medium.com/master-the-linux-chroot-command-a-comprehensive-guide-f2026f913726">https://hopeness.medium.com/master-the-linux-chroot-command-a-comprehensive-guide-f2026f913726</a>
    <p>Men jeg skal nok ikke opdatere kubuntu via chroot ... Risikerer
      jeg ikke at der kommer ged i kernen og boot ... osv.?</p>
    <p><br>
    </p>
    <p></p>
    <blockquote type="cite"
cite="mid:alpine.DEB.2.00.2405061420250.25206@noget.server.internal.stderr.dk">........<br>
      <blockquote type="cite">
        <br>
        Nu kan jeg starte f.eks. kubuntus dia (og libreoffice) fra en
        terminal, og hvis jeg gør det med et &amp; efter, fungerer
        fungerer programmet videre selv efter exit fra chroot.
        <br>
        <br>
        Hvad synes I om min løsning?
        <br>
      </blockquote>
      <br>
      Jeg har haft noget i samme stil (med /home bind-mounted) for at
      kunne bruge en ældre version af bl.a. xpra.
      <br>
      <br>
      Jeg havde alle mine bind-mounts i /etc/fstab og en desktop
      launcher, der "run in terminal" kørte
      <br>
      <br>
      su -c "chroot /opt/wheezy /bin/su - stderr -c
      /usr/bin/xfce4-terminal &amp; bg"
      <br>
      <br>
      (Med --userspec ville den linie sikkert kunne skæres kraftigt
      ned.)
      <br>
      <br>
      Launcher'en startede en terminal og alt startet i den terminal
      blev kørte fra en wheezy installation, jeg havde debootstrap'et i
      /opt/wheezy.
      <br>
      <br>
      Det virkede fint til mit formål.
      <br>
    </blockquote>
    <p>Sejt!</p>
    <blockquote type="cite"
cite="mid:alpine.DEB.2.00.2405061420250.25206@noget.server.internal.stderr.dk">
      <br>
      <blockquote type="cite">Det er selvfølgelig ikke uproblematisk at
        køre to forskellige systemer på samme home-partition, men hvis
        man ikke bruger samme programmer på dem, burde det vel ikke
        skabe de store problemer?
        <br>
      </blockquote>
      <br>
      Hvis programmer opførte sig nogenlunde pænt, ville det heller ikke
      være noget problem, at køre de samme programmer på samme homedir.
      <br>
      <br>
      Da jeg var studerende var vores homedirs mountet på Linux, HP-UX,
      IRIX, Solaris, ... og jeg tænkte ikke ret meget over, om jeg kunne
      tillade mig, at starte et program på en given platform eller ej.
      <br>
      <br>
      Men jeg ved godt, at der er nogle programmer, der meget gerne vil
      lave en "upgrade" af deres config i ~/.config uden at tænke over,
      at man måske deler sit homedir mellem mange forskellige
      installationer. Det er eet af problemer ved, at nogen ikke længere
      ser Linux som et multi-user system i UNIX-familien.
      <br>
    </blockquote>
    <p>Tak!</p>
    <p>Flemming<br>
    </p>
    <p><br>
    </p>
    <div class="moz-signature">-- <br>
      Flemming TH Bjerke
      Tlf. 22120366</div>
  </body>
</html>

--------------A0CXRZ2gthScJamFGF8oVaH9--