IRC chat logs for #ltsp on irc.libera.chat (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:00 | georgeneophytou has joined IRC (georgeneophytou!~georgeneo@217.27.33.213) | |
| 06:11 | georgeneophytou has left IRC (georgeneophytou!~georgeneo@217.27.33.213, Quit: My MacBook has gone to sleep. ZZZzzz…) | |
| 06:12 | alkisg_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:14 | ricotz 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:25 | georgeneophytou 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:35 | georgeneophytou has left IRC (georgeneophytou!~georgeneo@217.27.33.213, Quit: My MacBook has gone to sleep. ZZZzzz…) | |
| 06:43 | woernie has joined IRC (woernie!~werner@p50867A20.dip0.t-ipconnect.de) | |
| 06:56 | alkisg_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:09 | georgeneophytou has joined IRC (georgeneophytou!~georgeneo@217.27.33.213) | |
| 07:17 | georgeneophytou has left IRC (georgeneophytou!~georgeneo@217.27.33.213, Quit: My MacBook has gone to sleep. ZZZzzz…) | |
| 07:19 | georgeneophytou has joined IRC (georgeneophytou!~georgeneo@217.27.33.213) | |
| 07:24 | georgeneophytou 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:46 | Durok has joined IRC (Durok!5f5ac874@ip5f5ac874.dynamic.kabel-deutschland.de) | |
| 07:56 | kjackal 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:00 | georgeneophytou 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:01 | georgeneophytou 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:18 | statler 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:21 | georgeneophytou 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:27 | georgeneophytou 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:28 | georgeneophytou 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:48 | statler 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:02 | kjackal_v2 has joined IRC (kjackal_v2!~quassel@athedsl-4546118.home.otenet.gr) | |
| 09:02 | kjackal has left IRC (kjackal!~quassel@2a02:587:3107:2e00:dfe:c076:99b8:91ef, Ping timeout: 276 seconds) | |
| 09:09 | adrianorg has joined IRC (adrianorg!~adrianorg@191.32.96.224) | |
| 09:20 | georgeneophytou 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:58 | Durok has left IRC (Durok!5f5ac874@ip5f5ac874.dynamic.kabel-deutschland.de, Remote host closed the connection) | |
| 10:06 | Durok 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:18 | adrianor1 has joined IRC (adrianor1!~adrianorg@177.18.172.1) | |
| 10:22 | adrianorg has left IRC (adrianorg!~adrianorg@191.32.96.224, Ping timeout: 265 seconds) | |
| 10:25 | woernie has left IRC (woernie!~werner@p50867A20.dip0.t-ipconnect.de, Remote host closed the connection) | |
| 11:24 | georgeneophytou has joined IRC (georgeneophytou!~georgeneo@217.27.33.213) | |
| 12:09 | Faith has joined IRC (Faith!~Paty_@unaffiliated/faith) | |
| 12:11 | section1 has joined IRC (section1!~section1@178.33.109.106) | |
| 12:54 | os_a has joined IRC (os_a!~Thunderbi@195.112.116.22) | |
| 13:43 | woernie has joined IRC (woernie!~werner@p50867A20.dip0.t-ipconnect.de) | |
| 14:26 | woernie 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:47 | georgeneophytou has left IRC (georgeneophytou!~georgeneo@217.27.33.213, Quit: My MacBook has gone to sleep. ZZZzzz…) | |
| 14:58 | georgeneophytou 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:02 | georgeneophytou has left IRC (georgeneophytou!~georgeneo@217.27.33.213, Client Quit) | |
| 15:03 | georgeneophytou 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:13 | georgeneophytou 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:39 | statler 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:47 | kjackal_v2 has left IRC (kjackal_v2!~quassel@athedsl-4546118.home.otenet.gr, Ping timeout: 268 seconds) | |
| 16:49 | kjackal 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:14 | ltsp_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:22 | vagrantc 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:37 | woernie_ 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:39 | Durok 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:02 | adrianorg 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:04 | adrianor1 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:09 | ltsp_user50 has left IRC (ltsp_user50!5b595a44@HSI-KBW-091-089-090-068.hsi2.kabelbw.de) | |
| 19:55 | section1 has left IRC (section1!~section1@178.33.109.106, Quit: Leaving) | |
| 19:56 | mgariepy has left IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy, Remote host closed the connection) | |
| 20:00 | adrianor1 has joined IRC (adrianor1!~adrianorg@186.213.156.55) | |
| 20:02 | adrianorg has left IRC (adrianorg!~adrianorg@177.156.62.7, Ping timeout: 240 seconds) | |
| 20:10 | kjackal has left IRC (kjackal!~quassel@2a02:587:3107:2e00:c8ea:ac45:e32f:94d8, Quit: No Ping reply in 180 seconds.) | |
| 20:10 | kjackal has joined IRC (kjackal!~quassel@2a02:587:3107:2e00:c8ea:ac45:e32f:94d8) | |
| 20:13 | woernie_ has left IRC (woernie_!~werner@p5B296156.dip0.t-ipconnect.de, Remote host closed the connection) | |
| 20:34 | adrianorg has joined IRC (adrianorg!~adrianorg@177.156.57.17) | |
| 20:35 | adrianor1 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:39 | ltsp_user20 has joined IRC (ltsp_user20!5f5ac874@ip5f5ac874.dynamic.kabel-deutschland.de) | |
| 20:48 | Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Quit: Leaving) | |
| 20:52 | shored has left IRC (shored!~shored@87-92-122-167.bb.dnainternet.fi, Read error: Connection reset by peer) | |
| 20:52 | shored 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:03 | ricotz 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:41 | kjackal has left IRC (kjackal!~quassel@2a02:587:3107:2e00:c8ea:ac45:e32f:94d8, Ping timeout: 246 seconds) | |
| 21:41 | kjackal 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:22 | bengoa has left IRC (bengoa!~alberto@194.50.55.200, Ping timeout: 265 seconds) | |
| 23:29 | adrianor1 has joined IRC (adrianor1!~adrianorg@177.132.222.145) | |
| 23:29 | adrianorg has left IRC (adrianorg!~adrianorg@177.156.57.17, Ping timeout: 240 seconds) | |
| 23:54 | adrianor1 has left IRC (adrianor1!~adrianorg@177.132.222.145, Ping timeout: 240 seconds) | |
| 23:59 | adrianorg has joined IRC (adrianorg!~adrianorg@177.18.173.66) | |