LTSP 5 is in minimal maintenance mode
The new LTSP is hosted at https://ltsp.github.io

IRC chat logs for #ltsp on irc.freenode.net (webchat)


Channel log from 17 October 2019   (all times are UTC)

05:19
<ltsp>
Error: "bot" is not a valid command.
05:21
<josht>
@alkisg I'm using a debian virtualbox install with fixed disk size, copied the vmdk to /srv/ltsp/images
05:21
ran ltsp image debian and it completed file
05:22
but when I pxe boot a client I get a error: mount: mounting /dev/loop0 on /root/ failed: No such Device
05:22
i tested the NFS server and can mount and view files fine
05:22
<vagrantc>
alkisg: introducing the "ltsp" binary package will wait in NEW until reviewed
05:22
<alkisg>
vagrantc: by whom? Aren't you the one doing the review?
05:23
josht: did you copy it, or symlink it?
05:24
<josht>
copy
05:24
<alkisg>
There are two ways:
05:24
put image in /srv/ltsp/images/image.img and NOT run ltsp image, just ltsp kernel, or
05:24
put image in /srv/ltsp/image.img and run ltsp image
05:24
<josht>
ahh ok
05:24
<alkisg>
In both cases, you can symlink that file to your original vbox dir, so that you don't have to copy
05:25
if you put it to images/image.img and run ltsp image, it'll try to overwrite itself
05:25
<vagrantc>
alkisg: no
05:25
alkisg: it's reviewed by ftp-masters
05:25
<alkisg>
OK; well then better sooner than later :)
05:25
Thanks!
05:26
<vagrantc>
alkisg: in theory, though in practice it can be hours, minutes, or months
05:26
<josht>
Thanks alkisg I'll have another go
05:26
<alkisg>
Meh mediawiki spam filed up the ltsp.org server
05:27
No free space for channel logging anymore
05:27
<vagrantc>
alkisg: i can maybe gentle request review ...
05:27
<alkisg>
vagrantc: great; but let's get it to new first, so that we do our part...
05:28
Is this always the case after major rewrites?
05:28
<vagrantc>
alkisg: indeed :)
05:28
alkisg: only if you change package names
05:28
<alkisg>
Gotcha
05:28* alkisg waves; breakfast time
05:28
<vagrantc>
dropping packages is fine(though requires some review for unstable->testing), adding packages requires review
05:29
er, adding requires *more* review :)
05:29
<alkisg>
:D
05:30
<josht>
another question, this time regarding booting iso's directly
05:31
as a livecd
05:31
should I just be copying the blah.iso into /srv/ltsp/images/blah.img
05:31
and running ltsp -o ipxe
05:32
I've tried it with the tails live cd and I get a file not found error for /ltsp/tails/vmlinux
06:00georgeneophytou has joined IRC (georgeneophytou!~georgeneo@217.27.33.213)
06:11georgeneophytou has left IRC (georgeneophytou!~georgeneo@217.27.33.213, Quit: My MacBook has gone to sleep. ZZZzzz…)
06:12alkisg_android has joined IRC (alkisg_android!~yaaic@5-203-224-168.mobile.nym.cosmote.net)
06:13
<alkisg_android>
johst, also run ltsp kernel before ltsp ipxe
06:13
<josht>
Thank you!
06:14ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
06:14
<alkisg_android>
wait, boot as live cd or in ltsp mode?
06:15
ltsp mode is easier as you dont care to find out the correct cmdline
06:15
<josht>
as a live CD
06:15
can I boot a .iso in ltsp mode?
06:16
<alkisg_android>
yes
06:16
otherwise, its like this https://github.com/ltsp/community/wiki/Non-LTSP-iPXE-entries
06:16
ltsp mode is a lot better and easier
06:17
<josht>
I'll try ltsp mode
06:17
thank you
06:17
<alkisg_android>
np
06:25georgeneophytou has joined IRC (georgeneophytou!~georgeneo@217.27.33.213)
06:33
<josht>
alkisg_android - working now - thank you so much
06:34
ltsp can't extract the kernel from the tails iso but if you mount it you can manually find it and copy across
06:35georgeneophytou has left IRC (georgeneophytou!~georgeneo@217.27.33.213, Quit: My MacBook has gone to sleep. ZZZzzz…)
06:43woernie has joined IRC (woernie!~werner@p50867A20.dip0.t-ipconnect.de)
06:56alkisg_android has left IRC (alkisg_android!~yaaic@5-203-224-168.mobile.nym.cosmote.net, Read error: Connection reset by peer)
06:56
<alkisg>
josht: you may use the --kernel-initrd parameter to tell ltsp where the kernel is
06:57
<josht>
ok, I'll give that a go
06:57
<alkisg>
How are the kernel/initrd named in the live iso?
06:59
<josht>
they are named initrd.img and vmlinux inside the live folder at the root where you mount the iso
07:00
<alkisg>
man ltsp kernel => examples
07:00
ltsp kernel --kernel-initrd="live/vmlinux-* s|vmlinux|initrd.img|"
07:00
And if you want you may open an ltsp/ltsp issue to put this upstream
07:01
Do mention the exact iso name where this is found
07:01
<josht>
ok, will do!
07:07
<alkisg>
Whoops sorry without the -* there
07:07
ltsp kernel --kernel-initrd="live/vmlinux s|vmlinux|initrd.img|"
07:09georgeneophytou has joined IRC (georgeneophytou!~georgeneo@217.27.33.213)
07:17georgeneophytou has left IRC (georgeneophytou!~georgeneo@217.27.33.213, Quit: My MacBook has gone to sleep. ZZZzzz…)
07:19georgeneophytou has joined IRC (georgeneophytou!~georgeneo@217.27.33.213)
07:24georgeneophytou has left IRC (georgeneophytou!~georgeneo@217.27.33.213, Quit: My MacBook has gone to sleep. ZZZzzz…)
07:27
<meo>
you're trying to run *tails* from network boot?
07:28
<josht>
no, it just a iso i had to hand
07:28
just playing at the moment
07:46Durok has joined IRC (Durok!5f5ac874@ip5f5ac874.dynamic.kabel-deutschland.de)
07:56kjackal has joined IRC (kjackal!~quassel@2a02:587:3107:2e00:dfe:c076:99b8:91ef)
07:57
<Durok>
Hi, with the new LTSP version how do I implement guest sessions? So far I have a working setup with the guests home folders on an NFS share (/home/nfs) as described here: https://github.com/ltsp/ltsp/blob/master/docs/ltsp-nfs.8.md.That was easy to do, but how can I modify the guest folder (deleting the folder and recreating it from a template)
07:57
before login?I tried it with a POST_INIT_="" line in ltsp.conf. That failed apparently because it got executed before the NFS share was mounted.I would be happy getting some tips to put me in the right direction!
07:59
<alkisg>
Durok: you create a custom session in /usr/share/xsessions/guest.desktop
07:59
And you put: Exec=your-script
08:00
That script deletes whatever it wants, initializes content, and finally it execs the real session
08:00georgeneophytou has joined IRC (georgeneophytou!~georgeneo@217.27.33.213)
08:00
<alkisg>
Someone should really write a wiki page about that :)
08:00
It's a very common question
08:01
This method works with any installation, it's not ltsp specific, but people are confused because the old ltsp had some failed attempts for implementing kiosk/guest sessions internally...
08:01georgeneophytou has left IRC (georgeneophytou!~georgeneo@217.27.33.213, Client Quit)
08:02
<Durok>
Ah thank you very much! I will try that now.
08:02
Yeah that was probably what blindfolded me :D
08:03
<alkisg>
Durok: well if you write a wiki page after you've done it, lots of people will thank you :)
08:04
<Durok>
Might try that, after I get everything working correctly
08:05
<woernie>
How do I mount smb-shares for my users and clients(thin & fat). Users authenticate against a Samba-DC, but I can not mount users smb-home and group-shares.
08:06
<alkisg>
woernie: ltsp5 or ltsp19?
08:08
<woernie>
ltsp5 where I can look this up i'm pretty new to ltsp and I installed it a few mounth ago
08:08
<alkisg>
ltsp-info | nc termbin.com 9999
08:08
This tells us all the necessary information
08:10
<woernie>
ltsp5 on Ubuntu 18.04.3 LTS
08:10
<alkisg>
So I'm guessing you didn't set up authentication in the chroot; you're still using ssh for authentication
08:11
How would you mound smb if you weren't using ltsp? By fstab? By pam?
08:13
<woernie>
authentication by PAM I tried mounts by fstab , also by ltsp and by Pam but I couldn't figured it out.
08:14
<alkisg>
LTSP5 doesn't support PAM
08:14
LTSP19 supports PAM
08:14
So the idea is that each user mounts his own share after authentication?
08:14
<woernie>
yes
08:15
<alkisg>
Did you make this work without ltsp?
08:15
<woernie>
yes with pam on pure linux clients
08:15
<alkisg>
OK then it should be doable with LTSP19
08:16
Note that LTSP19 doesn't support thin clients
08:16
<woernie>
can I update from ltsp5 to ltsp19
08:16
<alkisg>
Not really, it's very different. You can keep both ltsp5 and ltsp19 installed, but only one of them can be active (due to dnsmasq.conf)
08:17
Another idea would be to just mount everything on the server even if it's smb, and then let the clients use the default sshfs
08:17
I.e. abort the "user mounts" idea and keep on using ltsp5
08:18statler has left IRC (statler!~Georg@p5B30EE2F.dip0.t-ipconnect.de, Remote host closed the connection)
08:18
<woernie>
I will have a look at the sshfs.
08:19
<alkisg>
sshfs is the default, you don't need to do anything for that, just mount /home/users on the server
08:19
and sshfs will use it
08:20
<woernie>
and where I mount the others shares
08:20
<alkisg>
getent passwd user
08:20
=> tells you the path to the user home
08:21
If it's /home/user, then that directory or symlink should exist
08:21
if it's a symlink, the target (real mount) can be anywhere
08:21georgeneophytou has joined IRC (georgeneophytou!~georgeneo@217.27.33.213)
08:23
<woernie>
do I mount this with fstab or lts.conf
08:25
<alkisg>
On the server? fstab. lts.conf is only for the clients.
08:27georgeneophytou has left IRC (georgeneophytou!~georgeneo@217.27.33.213, Quit: My MacBook has gone to sleep. ZZZzzz…)
08:27
<woernie>
who I handle the credential? my fstab://debian-df/gemeinsam /media/server/gemeinsam cifs gid=10005,username=werner,password=XXXXXX,file_mode=0664,dir_mode=0770 0 0
08:28georgeneophytou has joined IRC (georgeneophytou!~georgeneo@217.27.33.213)
08:28
<alkisg>
Didn't you say you managed to do it without ltsp?
08:28
It's the same on the server too
08:30
You can either mount a global "users" directory from cifs, which has subdirectories like "users/user1, users/user2" etc,
08:30
or you can have multiple fstab lines , one for each user, "users/user1", "users/user2" etc in fstab
08:35
<woernie>
without ltsp I managed it by pam_mount.conf
08:37
<alkisg>
This only works for one user
08:37
Now you need to mount multiple directories (or a central one)
08:48statler has joined IRC (statler!~Georg@gwrz.lohn24.de)
08:49
<woernie>
looks good thanks. I will have a look if the rights are right
08:49
<alkisg>
Right :)
09:02kjackal_v2 has joined IRC (kjackal_v2!~quassel@athedsl-4546118.home.otenet.gr)
09:02kjackal has left IRC (kjackal!~quassel@2a02:587:3107:2e00:dfe:c076:99b8:91ef, Ping timeout: 276 seconds)
09:09adrianorg has joined IRC (adrianorg!~adrianorg@191.32.96.224)
09:20georgeneophytou has left IRC (georgeneophytou!~georgeneo@217.27.33.213, Quit: My MacBook has gone to sleep. ZZZzzz…)
09:32
<woernie>
hello again. for my thinclients it works fine, but not for the fatclients. I see the directories but only root can mount in lts.conf I have FSTAB_1="server:/media/server/gemeinsam /media/server/gemeinsam sshfs defaults,nolock 0 0"
09:58Durok has left IRC (Durok!5f5ac874@ip5f5ac874.dynamic.kabel-deutschland.de, Remote host closed the connection)
10:06Durok has joined IRC (Durok!5f5ac874@ip5f5ac874.dynamic.kabel-deutschland.de)
10:09
<woernie>
I tried it with nfs but I get also only root can mount
10:18adrianor1 has joined IRC (adrianor1!~adrianorg@177.18.172.1)
10:22adrianorg has left IRC (adrianorg!~adrianorg@191.32.96.224, Ping timeout: 265 seconds)
10:25woernie has left IRC (woernie!~werner@p50867A20.dip0.t-ipconnect.de, Remote host closed the connection)
11:24georgeneophytou has joined IRC (georgeneophytou!~georgeneo@217.27.33.213)
12:09Faith has joined IRC (Faith!~Paty_@unaffiliated/faith)
12:11section1 has joined IRC (section1!~section1@178.33.109.106)
12:54os_a has joined IRC (os_a!~Thunderbi@195.112.116.22)
13:43woernie has joined IRC (woernie!~werner@p50867A20.dip0.t-ipconnect.de)
14:26woernie has left IRC (woernie!~werner@p50867A20.dip0.t-ipconnect.de, Ping timeout: 246 seconds)
14:26
<georgeneophytou>
I have changed the subnet which the LTSP server lives, clients can no longer boot, what is needed here? Do I need to reconfigure DHCPproxy?
14:28
im looking at /etc/dnsmasq.d/ltsp-dnsmasq.conf lines 29 and 33, here I can see the old subnet
14:28
now should I modify this file directly or is there another method?
14:32
I have edited this file directly and restarted dnsmasq service, clients can boot again
14:47georgeneophytou has left IRC (georgeneophytou!~georgeneo@217.27.33.213, Quit: My MacBook has gone to sleep. ZZZzzz…)
14:58georgeneophytou has joined IRC (georgeneophytou!~georgeneo@217.27.33.213)
14:59
<alkisg>
georgeneophytou: ltsp -o dnsmasq, when the subnet is changed
15:01
<georgeneophytou>
thanks alkisg
15:01
<alkisg>
np
15:02georgeneophytou has left IRC (georgeneophytou!~georgeneo@217.27.33.213, Client Quit)
15:03georgeneophytou has joined IRC (georgeneophytou!~georgeneo@217.27.33.213)
15:03
<georgeneophytou>
are there currently any options to run LTSP server in high availability? or to have backup LTSP server?
15:05
<alkisg>
You can do various things for that; ltsp doesn't have any code regarding this though
15:05
E.g. if you have 2 proxydnsmasq servers, one of them will answer anyway
15:05
If you use ceph, it's distributed
15:05
<georgeneophytou>
im trying to find a solution currently to have a backup in case the primary LTSP server goes down
15:06
so firstly I will need a way to mirror files and users between the two server
15:06
<alkisg>
A daily backup via rsync is usually good enough
15:07
Overengineered solutions are frequently error prone
15:07
<georgeneophytou>
true true
15:07
<alkisg>
E.g. if you have a raid, you can just put the server disks to a second server in 2 minutes
15:08
<georgeneophytou>
can you explain that please?
15:08
<alkisg>
That, along with a daily rsync/backup, is usually fine
15:08
E.g. suppose you install the server with 3 disks in raid-5
15:09
That gives you disk space of 2 disks
15:09
If the server hardware fails, board, cpu, whatever, you move those disks to another server
15:09
And it just boots; linux doesn't care about hardware changes
15:09
If one disk fails, it's still fine, because of raid
15:10
So the only part that can actually cause issues is if the file system fails, or if rm -rf / is executed, etc,
15:10
that's where the daily backup helps
15:11
<georgeneophytou>
yes you have a point
15:13georgeneophytou has left IRC (georgeneophytou!~georgeneo@217.27.33.213, Quit: My MacBook has gone to sleep. ZZZzzz…)
16:39
<Durok>
Heyho I made a short write-up for setting up guest sessions. All feedback is very much welcome, including better and easier ways to set this up.
16:39
https://durok.tech/gitea/durok/LTSP_19_GUESTS
16:39statler has left IRC (statler!~Georg@gwrz.lohn24.de, Remote host closed the connection)
16:41
<fiesh>
nice
16:43
<alkisg>
Durok: no no no no! This is the correct place! :D https://github.com/ltsp/community/wiki
16:43
This will help developers fix a few inaccuracies, and help users contribute more, and help the content become better
16:44
<Durok>
As soon as I know how to put it there I will!
16:44
<alkisg>
Just click edit
16:44
It's user-editable
16:44
<ogra>
but users need to click ?
16:44
<alkisg>
You sign-in to github first of course
16:44
ogra: yes! They'll also probably need a mouse!
16:44
<ogra>
you're always making it sooo hard !!!
16:44
<Durok>
Found it thanks!
16:45
<ogra>
:D
16:45* alkisg isn't sure if github also requires a cat and a dog, but definitely a mouse
16:46
<Durok>
Seems to work.
16:46
https://github.com/ltsp/community/wiki/Guest-session-for-LTSP-19
16:46
<alkisg>
Durok: no need for LTSP 19; Guest session is enough
16:46
As it's in the ltsp19 wiki (which will become ltsp20 next year)
16:47
<ogra>
one hopes ...
16:47kjackal_v2 has left IRC (kjackal_v2!~quassel@athedsl-4546118.home.otenet.gr, Ping timeout: 268 seconds)
16:49kjackal has joined IRC (kjackal!~quassel@2a02:587:3107:2e00:c8ea:ac45:e32f:94d8)
16:50
<alkisg>
Durok: ltsp nfs --nfs-home=1 => automatically creates the exports for /home
16:50
LIGHTDM_CONF='user-session=guest' ==> nice one ;)
16:51
Also note that if your clients have enough ram to fit their /home/guest in it, then you may use a single account for any number of clients, without even using nfs for /home
17:00
<Durok>
alkisg: Changed the nfs section. Yeah I couldn't get the one user setup to work. Might try that tomorrow.
17:01
<alkisg>
Durok: ping me if you need help anywhere
17:03
Btw if you put the session in /etc/ltsp, and symlink it to /usr/share/xsessions with a POST_INIT command, then you don't need `ltsp image`, and you can also use live CDs for the image etc etc; it's not "guest specific"
17:04
In other words, putting all image customizations in /etc/ltsp allows one to just run `ltsp initrd` and use any non-customized chroot
17:06
Ubuntu 19.10: The Chromium browser is only available as a snap in 19.10. This blog post has more details. ==> meeeeh
17:06* alkisg will need to copy it from debian to the ppa :/
17:07
<ogra>
or point people to firefox
17:09
(i thought you had snaps working)
17:10
<alkisg>
Oh snaps are working fine, but I still hate the idea :)
17:11
It's like we're moving to windows 3.11 after 20 years in linux
17:11
<ogra>
because you dont have to maintain chromium ;)
17:11
<alkisg>
Eh, debian will maintain it anyway
17:11
No need for any ubuntu developer to spend time on it :)
17:11
<ogra>
from a dev POV it is the greatest improvement in the lat decade
17:11
*last
17:12
<alkisg>
If the .deb infrastructure needs fixing, by all means it should be done
17:12
But bundling the dependencies sounds so silly
17:12
<ogra>
creating snaps is a breeze (not even 10% of the wrk a deb takes) ... maintaining and keeping them up to date too ...
17:12
<alkisg>
It introduces security issues instead of fixing them
17:12
Eh, create an easy way to make .debs then
17:12
Even .spec to deb, so that it's cross platform
17:13
<ogra>
yes, they are slightly bigger but they are a highly compressed, GPG signed squashfs ... that compensates for the size again
17:13
<alkisg>
squashfs is usually bigger than tar.xz
17:13
And all those loop mounts.... look awful
17:13
<ogra>
but you cant run a tar.gz ... and it is really really hard to make a tar.gz readonly ;)
17:14
<quinox>
(I dislike snaps, but it's not strictly "windows 3.11": mac applications are big folders that also contain all of their dependencies)
17:14
<alkisg>
I think the only benefit for appimage/snaps/flatpaks etc are for unsafe, non open source code, that needs to run sandboxed
17:14
And I avoid such apps
17:14
<ogra>
nah
17:14
also you cant really compare the three at all
17:14
<alkisg>
Macs also need to run unsafe code
17:14
<ogra>
snaps are designed originaly for cli and server
17:14ltsp_user50 has joined IRC (ltsp_user50!5b595a44@HSI-KBW-091-089-090-068.hsi2.kabelbw.de)
17:15
<ogra>
desktop came later ...
17:15
appimage and flatpak are just delivery/snadbox mechanisms for desktop apps
17:15
<alkisg>
Anyway, I hope all this sandboxing bubble will soon go away, and developers will again focus in normal packaging with normal dependencies
17:15
<ogra>
i doubt that
17:16
<alkisg>
I really wouldn't like to have to worry "oh are any of my 1234 snaps affected by this security flaw in this library?"
17:16
<fiesh>
appimage is great for deploying pre-compiled applications
17:16
like games or something
17:16
<ogra>
if you have a desktop :)
17:16
alkisg, well, that shows you never maintained a snap ;)
17:17
<fiesh>
not saying I'm a big fan of things not included in the distribution's package manager, but sometimes such software exists
17:17
<ogra>
as a developer the store regulary sends you security audits of your snap
17:17
<alkisg>
Truly, and I see so many down sides in their architecture, that I'll switch to debian if I ever have to use snaps in Ubuntu :)
17:17
<fiesh>
snap was really Ubuntu-centric though
17:17
<ogra>
(which you can indeed ignore ...)
17:17
<fiesh>
last time I checked
17:17
which I heavily disliked
17:17
<ogra>
has never been ubuntu centric
17:17
since we started to develo it in 2014
17:17
+p
17:18
we have tried to cover all distros from day one
17:18
<alkisg>
I don't think they're Ubuntu-centric; but usually things that are developed within Ubuntu, get ignored by Redhat etc... not all the times, but usually
17:18
<fiesh>
I remember that I looked into using them under Gentoo, and the bottom line was "ain't working"
17:19
<ogra>
sadly two days after we announced desktop support for snaps in 2016 RH freaked out and quickly turned xdg-app into flatpak and announced it as the new shiny app delivery mechanism
17:19
<alkisg>
At some point canonical was blamed for nih syndrome; but I do think that redhat has that
17:19
<ogra>
(and xdg-app had been dead in the water for years before)
17:19
alkisg, i wish they would be ignored by RH
17:20
sadly RH is actively firing against it ... that started with upstart (did you know lennart was an initial and active contributor to upstart ?)
17:21
<alkisg>
True, I think that upstart vs systemd does show RH's nih syndrome
17:21
<ogra>
well
17:22
i think the NIH syndrome is a made up myth :)
17:22vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
17:22
<ogra>
you have to invent things if you progress
17:22
<alkisg>
Well, if lawyers say "don't invest there because..." you reimplement from scratch
17:22
<ogra>
true, but thats has rarely happened
17:22
<alkisg>
However you might callthat
17:23
<ogra>
upstart was initially celebrated since we had something to show off against the new apple init technology ...
17:23
and there was nothing comparable to it
17:23
today the NIH topic is snaps ... "it is canonical flatpak"
17:24
<alkisg>
If (example) redhat ends up investing 90% of the code in upstart, and yet the initial copyright is canonical's, this gives fame to canonical at RH's expense
17:24
So managers may decide to reimplement instead
17:24
<ogra>
that snaps are 2 years older than flatpak and that both are technologically not even remotely comparable (pakage format vs desktop sandbox delivery tool) are completely ignored
17:25
<vagrantc>
but what they have in common is i've basically avoided either of them :)
17:25
<ogra>
haha, hey vagrantc
17:25* alkisg wholeheartily agrees with vagrantc this time :D
17:25
<vagrantc>
alkisg: that could be dangerous!
17:25
<alkisg>
I just stated that "if Ubuntu forces me to use snaps, I'll switch to Debian" :D
17:26
<ogra>
i love that i can have the latest VLC on my 16.04 desktop and be sure it is kept up to date by upstream
17:26
<alkisg>
Then make a tool for upstream to easily produce a .deb
17:26
No need to bundling dependencies
17:26
And if different versions of libraries are needed, make it happen for .debs too
17:26
<ogra>
they have debs ... and they need to build them for every distor and its grandchild separately
17:26
<alkisg>
Right, that can be avoided
17:27
<vagrantc>
i see the appeal of snap/flatpack/etc but it's not my style ... i'm moving into the guix/nix camp anyways :)
17:27
<ogra>
the snap they build runs the same on my 16.04 desktop as it runs on lennarts current fedora box ;)
17:27
<alkisg>
Google chrome sends the same .deb for any distro/version
17:27
They don't give differently compiled debs
17:27
<ogra>
because itis statically built
17:28
<alkisg>
And if one just builds an infrastructure for declaring dependencies, it can be done for all without static builds
17:28
A wrapper would state "I need libcXX, javaYY", and the proper paths would be set
17:28
<ogra>
so you would create another new package system ?
17:28
<vagrantc>
don't snaps or flatpacks typically bundle all their non-statically-built dependencies?
17:28
<ogra>
yes
17:28
<alkisg>
Not at all. Just support multiple libraries in the existing infrastructure
17:28
<ogra>
ther are library snaps
17:28
<vagrantc>
alkisg: that's an adventure debian-based systems are not well equipped for
17:29
<alkisg>
So one could have qt4 and qt5 installed in .deb format
17:29
And yet that's the proper solution, not snaps
17:29
<ogra>
or in snap format ;)
17:29
we have that
17:29
<alkisg>
snaps can declare external dependencies?
17:29
<vagrantc>
this is one case where i do think an alternative approach is more viable- packaging multiple concurrent versions of things.
17:29
<ogra>
KDE has nearly completely moved to snaps ... they have all the libs as content provide snap
17:30
<alkisg>
KDE or Kubuntu?
17:30
KDE on Fedora will use snaps?
17:30
<ogra>
you can declare a "default provider" snap ... that gives you your lib framework
17:30
KDE upstream
17:30
<alkisg>
If I have 1000 snaps that need qt5, do I have qt5 one time or 1000 times?
17:30
<ogra>
they have most of their apps in the snap store nowadays
17:30
and maintain them themselves
17:30
<vagrantc>
alkisg: ok, since i can land "ltsp" in experimental, i think i'll work on that first ... and then solve the stupid security issues with ldm
17:30
<alkisg>
vagrantc: great!
17:31
<vagrantc>
"solve" as in briefly test and announce and upload.
17:31
<ogra>
you have QT5 one time if the devs all used the same default provider
17:31* vagrantc has never waited so long on a one-line fix.
17:31
<ogra>
but sice snaps do not restrict you you will likely have some apps that simply bundle it for the ease of development
17:32
snaps are really for developers after all
17:33
you can build your app the arch/gentoo way by building *everything* from upstream source ... you and use the debian/ubuntu way and simply build against archive packages or you can build against a library snap that acts as default provider and only ship your app binary
17:33
<alkisg>
I don't think linux is ready for that kind of security flaw. If all apps come as binaries with whatever bundled dependencies, hackers will soon make us need an antivirus
17:33
<ogra>
so for ie. kubuntu and the ubuntu desktop you will have the lib snaps in use and small apps
17:34
for something third party you will likely rather see the bundled approach
17:34
<alkisg>
Anyways, ty for all the input; /me crosses fingers that he'll be able to continue using .debs for a long time :)
17:34
<mwalters>
isn't there already the risk of dependency hijacking (like with NPM) with how apt currently works?
17:34
<ogra>
not with a trusted archive
17:35
the prob is maintained scripts in debs
17:35
<mwalters>
sure, e.g., the official repos
17:35
<alkisg>
With apt, I can run `debsums` and check all the files in my hard disk against signed sources
17:35
<ogra>
and things like PPAs
17:35
<mwalters>
I'm not familiar with how the publishes is deemed trusted, so maybe I'm missing something
17:35
s/publishes/publisher
17:35
<ogra>
you can have a PPA that has "fancy-package-super-game", people add it ... the maintainer script now gets full root access to your system and can install any backdoor you want
17:36
<mwalters>
yes, that's what I'm talking about
17:36
<ogra>
well, as long as you stick with the default debian and ubuntu archives you are safe
17:36
<mwalters>
even with regard to universe/multiverse?
17:36
<ogra>
as soon as you add third party archives to apt it is a matter of luck and trust
17:36
<mwalters>
or are those "not default"?
17:36
<ogra>
they are default
17:37
<alkisg>
Universe/multiverse packages are still developed by debian/ubuntu developers
17:37
<ogra>
rigt
17:37
*right
17:37
inside a trusted archive
17:37
<mwalters>
Gotcha... so there isn't a similar attack vector as NPM
17:37woernie_ has joined IRC (woernie_!~werner@p5B296156.dip0.t-ipconnect.de)
17:37
<ogra>
well
17:37
<mwalters>
(or at least as big of a risk as NPM)
17:37
<alkisg>
So one would have to spend some time, to become one, and then risk everything to send malicious code, and then have his access revoked when discovered
17:37
<ogra>
we started snaps because we have numbers about PPA usage :)
17:38
te iitial idea was really to replace PPAs with something secure
17:38
<alkisg>
Meaning PPA usage is high, or low? I'd imagine high?
17:38
<ogra>
because people started more and more adding random libreoffice PPAs ... firefox PPAS etc etc
17:38
<alkisg>
How are snaps more secure than PPAs?
17:38
<Durok>
alkisg: Ah I really like the idea of symlinking the guest session. Completely forgot about the xorg symlink example. Changed it now.
17:38
<ogra>
they are completely confined ... a snap can not access anything by default
17:38
you need to declare interfaces
17:39
<alkisg>
Eh, they can just ask me "give yourpassword"
17:39
I don't consider that part security
17:39
<ogra>
these interfaces uderly certain rules and the sotre has checks for them when you upload
17:39Durok has left IRC (Durok!5f5ac874@ip5f5ac874.dynamic.kabel-deutschland.de, Remote host closed the connection)
17:39
<ogra>
so a camera app can not access your camera by default
17:39
<mwalters>
So there's still some form of curated repository?
17:39
<alkisg>
Sandboxing is fine for android, but I would never use android for my office desktop pc, I wouldn't trust it
17:39
<ogra>
the user needs to permit this or you need permission from the sotre after an app review
17:39
<mwalters>
(with "side loading" if you want to live dangerously?)
17:40
<ogra>
alkisg, how many tabs does your browser have open currently
17:40
<alkisg>
Currently 10, but I can easily reach 100
17:40
<ogra>
how many of them are sites that use a password
17:41
<alkisg>
When I go to google.com, I trust it with its password
17:41
<ogra>
and how are you sure one site cant read the passwords from another site you have open ?
17:41
<alkisg>
But I don't trust an app that can show me whatever picture it wants, and emulate a browser tab
17:41
<ogra>
say you have 5 forums open and do homebanking :)
17:41
<alkisg>
So that it would fool me into thinking I'm giving my password to google, when I'm giving it to the app
17:41
<mwalters>
I think ogra is referencing tab sandboxing
17:42
<ogra>
now all run inside the same password manager realm
17:42
<mwalters>
(so js from one page can't access the memory of another)
17:42
<alkisg>
Sandboxing is veeery different than "browser tabs"; browser tabs are clearly within my browser, not anywhere on my screen, emulating whatever
17:42
I do not use browser password manager for my bank accounts
17:42
<ogra>
now imagine i make snap webapps apps for these forums ...
17:42
<alkisg>
I don't trust them that much
17:43
<mwalters>
It's more about limiting access to cookies/localstorage, the entire process/memory structure of the other tab
17:43
<ogra>
the apps would be completely confined ... they cant read anything on your disk (except their own approved RW space) and cant access your browser password DB either
17:44
<alkisg>
But they can show a picture of google, where I would type my google password, and they'd read it from my keyboard
17:44
<ogra>
the point is that snaps can definitely not see anything of your system you dont allow explicitly
17:44
<mwalters>
I think any application could potentially do that currently?
17:44
<alkisg>
So you can do all the sandboxing you like, and the apps will still fool users
17:44
<ogra>
no diskspace, no devices, etc etc
17:44
<mwalters>
"You can't fix stupid" ;)
17:44
<ogra>
sure, there is always a matter of trust
17:45
but i.e. the firefox snap in the snap store is maintained by mozilla ...
17:45
the VLC snap comes from VLC
17:45
spotify from spotify
17:45
and you might feel a lot safer with the skype snap than by having some deb that can read your whole homedir
17:46* ogra goes afk for a moment
17:46
<alkisg>
Sandboxing may come to .debs too
17:46
It's not coupled to the delivery format
17:50
OK fortunately the debian package is called "chromium", so Ubuntu's transitional "chromium-browser" package won't upgrade it to snaps on each new version
17:51
Now we just need a script that automates copying debian packages to PPAs :D
17:51
<highvoltage>
what do you mean alkisg?
17:51
launchpad PPAs or independent ones?
17:52
<ogra>
well, sandboxing is only one minimal bit of snaps
17:52
<alkisg>
launchpad PPAs
17:52
<ogra>
transactional updates ... automatic rollback if the new app is buggy ...
17:52
<alkisg>
highvoltage: my main concern is that I won't be able to have chromium on 20.04 AND have snapd purged,
17:52
<ogra>
i.e. you have an "always on" gurarantee with snaps
17:53
<alkisg>
so one way to do that, is to copy the one from debian, to the greek schools ppa
17:53
<ogra>
biary delta upgrades ... (only get the changed bytes ... new snap is assmbled locally based on checksums and gpg keys)
17:53
<highvoltage>
(ah I see what you mean now)
17:54
<ogra>
... snapshots of your data ...
17:54
(versioned ones)
17:54
<alkisg>
ogra, if snaps were a replacement proposal for .debs, then I'd consider it; but they're not, they're focused on apps outside of normal repositories, which i really don't want in my system...
17:55
I don't think snaps goals include "completely replacing debs" in the future, do they?
17:55
<ogra>
they are the attempt to eable *everyone* to do very advanced packaging in less than a day
17:55
nope
17:55
<alkisg>
I would create a tool for that part, not a new packaging system
17:55
<ogra>
debs are actually still the base and the default is to build against archive debs
17:55
<alkisg>
Right, so I think all those nice things should go to .debs, not snaps
17:56
Even Turkey has delta updates for debs
17:56
<ogra>
if snas replace something it is rather PPAs
17:56
not debs
17:57
alkisg, right, transactional updates are not anything you can ever see in debs though ...
17:57
or rollbacks
17:57
but yeah, deltas are nearly everywhere nowadays
17:58
effectively more and more apps will vanish from the ubuntu archive though simply because they are painful to maintin there
17:58
<alkisg>
It would be nice to keep the debian versions there though, not make them disappear
17:59
Like chromium-browser
17:59
<ogra>
but debs wont die and the desktop/server/whatever will still be build out of debs
17:59
<alkisg>
It's in universe, it's already clear that it doesn't get security audits
17:59
<highvoltage>
lol nothing gets security audits
17:59
<ogra>
highvoltage, every single upload gets security audits
18:00
<highvoltage>
I don't believe that it gets a full security audit, sure changes maybe
18:00
<ogra>
every sanp gets regular audits even after the fact and you get regular notifications about outdated libs from the store as a dev
18:00
it does
18:00
<highvoltage>
but I don't believe that you've done a full audit on the kernel or chromium or libreoffice or any of the large packages
18:00
it would be a large multi-year project
18:00
<ogra>
yes, snaps exist since 2014
18:01
what do you think we worked on over these years ;)
18:01
<highvoltage>
checking for outdated libs is not the same as a security audit
18:01
<ogra>
indeed this is limited to known CVEs, but the security system from a dev POV is 100% better than in the deb world
18:02adrianorg has joined IRC (adrianorg!~adrianorg@177.156.62.7)
18:02
<ogra>
you dont get a full code audit indeed
18:02
(since you can simply also just package binaries and not build them at all thats impossible)
18:03
but thats why there is the confinement and interface system
18:04adrianor1 has left IRC (adrianor1!~adrianorg@177.18.172.1, Ping timeout: 240 seconds)
18:08
<ogra>
anyway, you dont have to like snaps ... several 100.000 downloads a day show that they are liked by enough people to survive even if not everyone uses them :)
18:09ltsp_user50 has left IRC (ltsp_user50!5b595a44@HSI-KBW-091-089-090-068.hsi2.kabelbw.de)
19:55section1 has left IRC (section1!~section1@178.33.109.106, Quit: Leaving)
19:56mgariepy has left IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy, Remote host closed the connection)
20:00adrianor1 has joined IRC (adrianor1!~adrianorg@186.213.156.55)
20:02adrianorg has left IRC (adrianorg!~adrianorg@177.156.62.7, Ping timeout: 240 seconds)
20:10kjackal has left IRC (kjackal!~quassel@2a02:587:3107:2e00:c8ea:ac45:e32f:94d8, Quit: No Ping reply in 180 seconds.)
20:10kjackal has joined IRC (kjackal!~quassel@2a02:587:3107:2e00:c8ea:ac45:e32f:94d8)
20:13woernie_ has left IRC (woernie_!~werner@p5B296156.dip0.t-ipconnect.de, Remote host closed the connection)
20:34adrianorg has joined IRC (adrianorg!~adrianorg@177.156.57.17)
20:35adrianor1 has left IRC (adrianor1!~adrianorg@186.213.156.55, Ping timeout: 268 seconds)
20:38
<vagrantc>
alkisg: will you be tagging a new version soon, or should i work from 19.09 ?
20:39ltsp_user20 has joined IRC (ltsp_user20!5f5ac874@ip5f5ac874.dynamic.kabel-deutschland.de)
20:48Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Quit: Leaving)
20:52shored has left IRC (shored!~shored@87-92-122-167.bb.dnainternet.fi, Read error: Connection reset by peer)
20:52shored has joined IRC (shored!~shored@87-92-122-167.bb.dnainternet.fi)
20:59
<vagrantc>
alkisg: oh, i remembered a trick to avoid the NEW queue ... we ship a new ltsp-server package and it Provides: ltsp :)
21:03ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)
21:31
<vagrantc>
manpages seem very brokened.
21:31
empty ltsp-dnsmasq.8 and none of the others installed.
21:41kjackal has left IRC (kjackal!~quassel@2a02:587:3107:2e00:c8ea:ac45:e32f:94d8, Ping timeout: 246 seconds)
21:41kjackal has joined IRC (kjackal!~quassel@athedsl-4546118.home.otenet.gr)
21:43
<vagrantc>
seems to be trying to fall back to go-md2man
22:57
apparently "
22:57
in debian stable and newer, there's a new "ronn" package...
22:57* vagrantc submitted a some pull requests
22:57
<vagrantc>
probably should've split them up more appropriately...
23:22bengoa has left IRC (bengoa!~alberto@194.50.55.200, Ping timeout: 265 seconds)
23:29adrianor1 has joined IRC (adrianor1!~adrianorg@177.132.222.145)
23:29adrianorg has left IRC (adrianorg!~adrianorg@177.156.57.17, Ping timeout: 240 seconds)
23:54adrianor1 has left IRC (adrianor1!~adrianorg@177.132.222.145, Ping timeout: 240 seconds)
23:59adrianorg has joined IRC (adrianorg!~adrianorg@177.18.173.66)