| xnox | vorlon: yes. | 00:00 |
|---|---|---|
| xnox | vorlon: bionic daily; eoan is fine. | 00:00 |
| vorlon | so we just need to sru back the snap base handling | 00:00 |
| xnox | vorlon: well.... bionic snap seeding in desktop is kind of by-hand; whilst eoan uses ./snap-tool and is nicer. | 01:11 |
| xnox | vorlon: i don't know what is the plan with backporting ./snap-tool to bionic..... | 01:11 |
| === cpaelzer__ is now known as cpaelzer | ||
| akik | what's ubuntu's policy on using NOPASSWD in sudoers? i'm asking because cloud-init is still doing it for the default user and cloud-init is originally a ubuntu project | 08:19 |
| cjwatson | I'm not sure there's a policy on it. cloud-init probably does so because there's no point in requiring a password in environments where users typically don't have a password set at all. | 08:30 |
| cjwatson | (For cloud guests the default user usually only authenticates using an SSH key) | 08:30 |
| akik | i mean it lessens security if there's a user account on the system that can get root access without password | 08:32 |
| akik | and there's not warning about it | 08:32 |
| cjwatson | You should ask the cloud-init people specifically | 08:32 |
| akik | they didn't see any problem with it | 08:32 |
| cjwatson | You aren't going to get anywhere looking for a policy stick to hit them with | 08:33 |
| cjwatson | IMO anyway | 08:33 |
| akik | i don't want to hit anybody, just want to make systems safer | 08:33 |
| akik | :) | 08:33 |
| cjwatson | ("policy isn't a stick to hit people with" is an old catchphrase in the Debian policy-authorship community) | 08:36 |
| cjwatson | You could also discuss it with the Ubuntu security team I suppose. No guarantee they'll agree with you of course | 08:43 |
| odc | akik: that's pretty much how it works on all "cloud" distros. It's a sane default. You can modify it if you want, but using passwords is very impractical on a large scale. | 10:08 |
| akik | odc: no it's not a sane default | 10:19 |
| maswan | I think it is a sane default | 10:19 |
| akik | cloud-init creates a default sudo NOPASSWD: user with no warning | 10:19 |
| maswan | yes, which is exactly what I'd expect, managing passwords is hardly something you want to deal with by default | 10:22 |
| odc | akik: in typical cloud deployments, we do not make a distinction between users and administrators. If someone has the ssh key to connect on a machine, then they can do anything they want. It has been like that for many years now. | 10:23 |
| akik | that's no excuse for keeping it that way | 10:24 |
| odc | well what would you do? | 10:24 |
| akik | security > convenience | 10:24 |
| akik | remove the NOPASSWD: from the sudo config | 10:24 |
| odc | and? what would be the password? | 10:25 |
| akik | whatever you set it as | 10:26 |
| akik | i'm not concerned about that | 10:26 |
| odc | and where was the password defined? in cloud-init? in clear-text? | 10:27 |
| akik | i'm not talking about getting rid of the ssh pki setup | 10:27 |
| maswan | just hardcode the password to "ubuntu"? | 10:27 |
| akik | just removing the default NOPASSWD: sudo config | 10:27 |
| akik | well now you're just being silly | 10:27 |
| odc | akik: you're just used to the old model. If you don't want someone to be root, just don't let him login to the machine at all. If you want to make sure an application cannot have root rights, run it in a container. That's pretty much ho it works now. | 10:31 |
| akik | it's not about "the old model". it's about obeying the normal system security practices | 10:32 |
| akik | ubuntu desktop doesn't do that, why should cloud-init do it? | 10:33 |
| akik | i'm sure if i suggested adding it to ubuntu desktop, it would be rejected | 10:33 |
| odc | because that's what people expect. Servers and desktop are managed in a different way. You don't do passwords when you manage hundreds or thousands of machines | 10:36 |
| odc | unless your server will be used by people you don't trust | 10:36 |
| akik | i'm sure you don't login to the shell with ssh if you "manage hundreds or thousands of machines" | 10:37 |
| akik | or you're doing it wrong then | 10:37 |
| odc | no, but ansible does | 10:37 |
| odc | also for debugging :( | 10:37 |
| odc | but i agree that immutable deployments are usually the best ^^ | 10:39 |
| === cpaelzer__ is now known as cpaelzer | ||
| sladen | xnox: was there some intermediate discussion that was missed? | 12:24 |
| xnox | sladen: no. it's been discussed for a while on-and-off for 1 year plus. | 12:25 |
| xnox | sladen: do you have some concerns? literarly all of our installer are dog slow to boot, compared with installed systems and it's bad. | 12:25 |
| xnox | sladen: i guess some flavours may be concerned about size. but we are talking about 11M difference in the age of booting of USB sticks, as nobody has floppies anymore. | 12:26 |
| xnox | sladen: and it pisses me off that a faster create & boot exists, and we are not using it =) | 12:27 |
| sladen | xnox: if I understand correctly, there's only a single metric (1:+1.14 space gzip:LZ4) LZ4 14% larger than gzip? | 12:27 |
| sladen | xnox: decompression should be +/- the same. | 12:28 |
| sladen | xnox: if not, there's something sub-optimal in the I/O stage. Like flushing/read size/blocking | 12:29 |
| sladen | xnox: ie. using a different, but near identical hammer, doesn't help if it's a screw, not a nail | 12:29 |
| TJ- | who's responsible for manpages.ubuntu.com ? | 12:49 |
| === ricab is now known as ricab|lunch | ||
| xnox | sladen: lz4 decompression with lz4 is 4x faster than gzip | 13:02 |
| xnox | sladen: lz4 compression is 20% faster than gzip | 13:02 |
| xnox | sladen: so update-initramfs -u speed inprovement is noticable, and speed boot is blazing fast. | 13:03 |
| xnox | sladen: decompression speed is not +/- the same. | 13:03 |
| xnox | it's like 1.6s vs 0.1s | 13:03 |
| xnox | sladen: the larger than gzip, is the only downside, with upsides in compression/decompression time | 13:04 |
| juliank | heh, launchpad lost another upload yesterday | 13:16 |
| juliank | I uploaded lvm2 for xenial and newer, and the bionic upload was never accepted into unapproved; but re-uploading it worked fine | 13:17 |
| juliank | :) | 13:17 |
| sladen | xnox: don't think the +/-20% is much to care about. gzip/zlib and LZ4 use the same tech which is string matching. Only real difference is that gzip has a Huffman coder on the front to squeeze the bits) ... which is where the extra 15% size reduction comes from, at the cost of doing bit shuffling to unpack those variable length symbols | 13:17 |
| sladen | xnox: however, the difference between 1.6s and 0.1s is *so* dramatic (for the same tech) that something /else/ is likely broken | 13:18 |
| sladen | xnox: (it should be the case that a 14% I/O saving is easily wiped out by the processing) | 13:19 |
| sladen | xnox: so, by all means go ahead; but the solution still appears to be trying alternative hammer, rather than understanding the problem | 13:19 |
| ogra | xnox, please take also into account that on Core the initrd is created off-device (being readonly at runtime), there the smallest size (uboot loading and moving the file in ram can be very slow with bigger initrd's) and decompression time are indeed more essential ... | 13:26 |
| sladen | xnox: with chunking + parallelisation (decoding while streaming), the overall time *should* trend to the time for the pure read() from the block-device. Which *should* mean that a 15% I/O saving results in a 14% start->finish timing | 13:27 |
| sladen | xnox: with further optimisations to order the CPIO, and returns files/chunks as soon-as-ready, it should be possible to get a boot time /faster/ than the pure decompression speed (because unused data is never even uncompressed!) | 13:30 |
| xnox | sladen: re:cpio ordering => i was pondering about that. But i'm not sure what the right order is, or if it matters. How do we get the file-listing of the full initrd? and stream things? or is it just a matter of putting init first? | 13:45 |
| xnox | sladen: i don't believe kernel can do chunking and parallelisation for decoding while streaming for the initrd. but i might be wrong. | 13:45 |
| xnox | sladen: ie. for lz4 we must use '-l' legacy format. | 13:46 |
| xnox | sladen: also, for the public cloud workloads we do want to trade size & IO for cpu time. Typically clouds have fast ssd/nvme storage, but overcommitted cpu. Thus 14% larger size, and 400% faster decompress is a win there, unlike bare metal. | 13:49 |
| sladen | xnox: yeah, latter is complete opposite of ogra's boot-off-serial-EEPROM example :-) | 13:50 |
| ogra | well, more SD/eMMC ... :) | 13:52 |
| sladen | xnox: chunking/parallelisation code would likely need writing. It might be possible to do that as a pure userspace ... minimum initramfs.cpio that unpacks an initramfs2.cpio | 13:52 |
| ogra | actual flash got rare nowadays ... to expensive | 13:53 |
| sladen | xnox: think the conclusion is that for /many/ use cases (perhaps even quite a lot), it's a cheap win (time taken to change a flag) | 13:54 |
| sladen | xnox: and that with specific, clearly defined use-cases; and spending 3 months testing+writing code where required, pretty much anything is optimisable/betterable. Probably by quite large percentages | 13:55 |
| rbasak | TJ-: the best general answer is to use the Vcs-* fields from debian/control. That tells you what the maintainer considers to be the normative VCS source. | 13:56 |
| rbasak | TJ-: however that field isn't currently maintained well in the case of Ubuntu packages that have deltas against Debian, unfortunately. | 13:57 |
| xnox | sladen: looking forward, we may be booting initrd-less in many cases. But then the question will come down to as to what i/o speed we get at the boot-protocol vs bootloader support - ie can grub/uboot/aboot/etc. boot lz4 compressed kernel image. and that is actually probably more interesting than initrd. | 13:58 |
| rbasak | Usually though if an Ubuntu delta exists and Vcs-* seems to point to Debian, that means that Ubuntu developers aren't maintaining the delta in a VCS. | 13:58 |
| xnox | sladen: i hope you do agree that using lzma makes no sense at all in the cloud or bare-metal installers. | 14:00 |
| TJ- | rbasak: what's that in relation to? I'm confused? | 14:00 |
| xnox | sladen: and it is a massive step up to use either gzip or lz4 for those. | 14:00 |
| sladen | xnox: LZMA is nuts for all use cases except one-time compress and TFTP/serial/EEPROM booting were I/O is the bottleneck | 14:01 |
| rbasak | 17:35 <TJ-> is there some voodoo to understanding where to find the actual, meaningful, git commit logs for package git repos? | 14:03 |
| rbasak | From above | 14:03 |
| TJ- | rbasak: oh! blimey, wasn't that yesterday? I thought you were on about manpages.ubuntu.com :D | 14:04 |
| rbasak | Essentially what I'm saying is that the git-ubuntu imports are guaranteed to reflect publication history in apt, and not necessarily what the developers of those packages actually use (Vcs-* is for that) | 14:04 |
| TJ- | rbasak: right; now I've got the context it makes sense :) | 14:04 |
| TJ- | rbasak: fortunately I didn't need to deep-dive the source after-all, turned out to be a simple LUKSv2 instead of LUKSv1 confused poor GRUB :) | 14:05 |
| sladen | xnox: gah. Forgot the actual reason for LZMA. It was CD-ROM booting | 14:07 |
| sladen | xnox: it was deployed for the Live-CD were CD-ROM I/O to boot was the overriding bottleneck | 14:08 |
| xnox | sladen: also size, we had to fit on 700MB and lzma gave us half the size than gzip | 14:08 |
| === ricab|lunch is now known as ricab | ||
| Laney | xnox: can you recommend a python binding to systemd that's in the archive and lets me list / enable / disable / start / stop units? | 15:32 |
| Laney | python3-systemd looks quite limited | 15:32 |
| Laney | or should I talk dbus? | 15:32 |
| xnox | Laney: and you want it for the user or system units? | 15:36 |
| gamester | Is ubuntu dev not receiving regular gnome updates? Is it just sitting on gnome 3.32? | 15:36 |
| Laney | xnox: system | 15:37 |
| Laney | gamester: it will do, we usually pick it up a bit later on | 15:37 |
| xnox | Laney: so list / start / stop / restart is doable over dbus. | 15:37 |
| Laney | xnox: yeah I know, just wondering if there are some handy bindings | 15:37 |
| Laney | I found 'psystemd' which looks nice but doesn't seem to be packaged | 15:39 |
| xnox | Laney: oh, and on the manager there is now EnableUnitFiles DisableUnitFiles MaskUnitFiles UnmaskUnitFiles nice. it wasn't used to be there. | 15:39 |
| xnox | Laney: maybe check what snapd uses... | 15:39 |
| ogra | dh_systemd ? | 15:40 |
| xnox | Laney: but also curious what you doing . | 15:40 |
| Laney | xnox: autopkgtest-cloud charm in python | 15:40 |
| * Laney eyes ogra with suspicion | 15:40 | |
| * ogra grins | 15:40 | |
| * xnox will start using snapd out of context, to get out of context responses from ogra from now | 15:40 | |
| xnox | on | 15:40 |
| xnox | =)))))) | 15:40 |
| Laney | xnox: need to enable the right number of template instances per the config | 15:40 |
| ogra | \o/ | 15:40 |
| xnox | Laney: arghuhghh | 15:40 |
| Laney | I'm trying to move all of the things that admins do by SSHing into the machine out into the charm | 15:41 |
| Laney | probably will end up at 'most' rather than 'all' though | 15:43 |
| Laney | https://paste.ubuntu.com/p/6RWj9j8wdT/ | 16:36 |
| Laney | not too hard | 16:36 |
| === ricab is now known as ricab|bbiab | ||
| === ricab|bbiab is now known as ricab | ||
| ahasenack | question, when I override dh_gencontrol, for the purpose of using a substvars file, when I call dh_gencontrol at the end, do I need to pass $@ or something like to it, preserving whatever command line arguments debhelper was going to give it? | 17:09 |
| ahasenack | ilike https://pastebin.ubuntu.com/p/TKC5t9CnRh/ | 17:10 |
| ahasenack | or just dh_gencontrol? | 17:10 |
| vorlon | ahasenack: just dh_gencontrol is sufficient, dh puts all the relevant information in environment vars so you don't have to repeat | 17:50 |
| ahasenack | vorlon: thanks | 17:50 |
| infinity | ahasenack: Also, $@ probably isn't what you think it is. It would call "dh_gencontrol override_dh_gencontrol". | 17:53 |
| ahasenack | heh, quite the loop | 17:53 |
| ahasenack | but somehow it avoided it, when I tested | 17:53 |
| infinity | Not a loop. Just a nonsensical argument to dh_gencontrol | 17:54 |
| infinity | $@ being a variable that substitutes in the current target. | 17:54 |
| ahasenack | I see | 17:55 |
| ahasenack | snapd's d/rules is sourcing /etc/os-release to check the ubuntu release the package is being build on, is that ok/stable? | 18:00 |
| ahasenack | specifically | 18:00 |
| ahasenack | "include /etc/os-release" | 18:01 |
| ahasenack | and then it decides on VERSION_ID | 18:01 |
| ahasenack | which seems to not change with point releases, i.e., trusty is 14.04.6, and VERSION_ID is 14.04 still | 18:01 |
| infinity | It's no worse than people build-depending on lsb-release and calling that, which is pretty common. | 18:01 |
| infinity | It's not meant to change with point release. | 18:01 |
| ahasenack | yeah, that is what I was reviewing, and I recently saw a debian package changing to os-release to avoid the build-dep on lsb-release | 18:02 |
| infinity | And why would knowing which point release you're building on be useful? | 18:02 |
| ahasenack | we need a certain libapt-pkg<abi> minimum version, and the automatic dependency via shlibs doesn't catch the specific version that has a bugfix we need | 18:02 |
| infinity | Point releases aren't a real thing anyway. It's just a snapshot in time of the parent release. | 18:02 |
| infinity | Uhh, wat? | 18:02 |
| infinity | If you need a minimum version of a build-dep, you have a versioned build-dep. | 18:03 |
| infinity | Not a hack in rules. | 18:03 |
| ahasenack | I'm using substvars in rules to construct the depends (not build-dep) | 18:03 |
| ahasenack | https://github.com/CanonicalLtd/ubuntu-advantage-client/issues/520#issuecomment-498417459 | 18:04 |
| infinity | Okay. Still not following how you'd need to care about the point release version. | 18:05 |
| ahasenack | I don't, I wanted to be sure VERSION_ID wouldn't incorporate the point release number, and break my series if ifeq | 18:05 |
| ahasenack | of* ifeq | 18:05 |
| infinity | Versioned build-dep on the version you want, versioned dep on the version you want. Don't really even need substvars there, unless you're trying really hard to build the same source on all releases. | 18:05 |
| ahasenack | I would check for 14.04, for example, not 14.04.N | 18:05 |
| ahasenack | the latter | 18:06 |
| ahasenack | same source on all releases | 18:06 |
| infinity | A fun goal, but don't be married to it either. Things get messy in a hurry sometimes. :) | 18:06 |
| ahasenack | and this is the first time we have such a variable dependency | 18:06 |
| * infinity glances at all the m4 in gcc's rules. | 18:06 | |
| ahasenack | yeah, keeping an eye on it, very carefully | 18:06 |
| ahasenack | python differences are annoying enough already between trusty and something more modern | 18:06 |
| infinity | And okay, if you wanted to make sure it WON'T incorporate the point release, as the man who updates that, I can assure you that it won't. ;) | 18:07 |
| infinity | It did once when someone else did it for me, and I fixed it in a hurry. :P | 18:07 |
| ahasenack | heh | 18:09 |
| ahasenack | infinity: and is /etc/os-release ok to source, or does it have to be parsed like /etc/lsb-release? | 18:10 |
| ahasenack | specifically, use "include /etc/os-release" in d/rules, like I've seen snapd do | 18:10 |
| infinity | https://www.freedesktop.org/software/systemd/man/os-release.html | 18:10 |
| ahasenack | aha, even better | 18:10 |
| infinity | ahasenack: The "spec" claims it should be okay to source. | 18:10 |
| infinity | ahasenack: And since I don't see any reason why we'd deviate from said spec, I think you're good to go. | 18:11 |
| ahasenack | thx | 18:11 |
| infinity | Hrm. | 18:12 |
| * infinity notes the addition of VARIANT and VARIANT_ID to the spec. | 18:13 | |
| infinity | Which are completely useless without a .d mechanism. | 18:13 |
| infinity | Cause I'm not letting every flavour overwrite os-release. | 18:13 |
| infinity | Oh well. | 18:13 |
| infinity | It was almost useful. Well job, systemd people. | 18:13 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!