=== vlm_ is now known as vlm
[05:06] <betuxy> Hey guys, I need a solution to realtime sync a log directory (so a lot of changes may occur) to a second server. lsyncd and mirror both explicitly say they're only suited for a slowly changing directory tree because the use of rsync.
[05:17] <mirespace> good morning
[05:18] <cpaelzer> hi mirespace
[05:18] <cpaelzer> and good morning everyone
[05:18] <utkarsh2102> mirespace: o/
[05:18] <utkarsh2102> cpaelzer: o/
[05:23] <cpaelzer> betuxy: IMHO this depends on what architecture you want/need - you could either go with central storage and remote access to it (like NFS) or to an FS that keeps itself synchronized (like glusterfs)
[05:23] <mirespace> o/
[05:29] <betuxy> cpaelzer: mh nfs share might work ill look into it
[05:32] <yurtesen> I made a very trivial debdiff for bug #1964881 and having trouble finding a sponsor. Does anybody have suggestion on how to solve this dilemma?
[05:32] <ubottu> Bug 1964881 in tomcat9 (Ubuntu) "Logging/Log rotation does not work for catalina.out" [Undecided, New] https://launchpad.net/bugs/1964881
[08:16] <betuxy> I have trouble exporting an nfs folder, my /etc/exports says "/var/log/user/test/application_logs 10.1.4.20(rw,sync,all_squash,anonuid=0,anongid=1000)"   however when i sync data on my client as root user the files have root:1030 as uid/gid  according to the ma n page all user/group should get squashed and set accordingly no?
[12:13] <ahasenack> morning
[12:14]  * kanashiro waves
[12:45] <athos> good morning!
[12:46] <athos> sergiodj: nice! Any luck on closing the tracks? 
[13:03] <trippeh> ubuntu isos doesnt appear to support netbooting isos directly using uefi httpclient. it works with Fedora.
[13:05] <trippeh> probably doesnt know what to do with the efi pmem block device the iso gets exposed over
[13:06] <trippeh> it does manage to load the initrd though, which has a fallback to downloading the iso itself
[14:28] <sergiodj> athos: yeah, I could close the channels without problems.  I initially closed just the 21.04 (for testing), but now I will close the rest
[15:11] <blackboxsw> renanrodrigo: Let's continue our original discussion from standup about the situation where python3's apt.Cache representing certain packages like 'cloud-init' 'python3' etc as not having an origin in 'main' when we query <apt.package.Package>.installed.origins we only see something like [<Origin component:'now' archive:'now' origin:'' label:'' site:'' isTrusted:False>]
[15:12] <renanrodrigo> exactly. just to make clear, packages don't have origins in APT - they have versions, and versions have origins
[15:12] <renanrodrigo> the version that comes installed in the image does not have any origin except from `now`
[15:12] <blackboxsw> renanrodrigo: I think the scenario where this happens is when a dated cloudimage is launched, we run apt update, but there has been a newer version of that package released. So apt doesn't see that currently installed version as "present" in the newly updated apt cache.
[15:13] <blackboxsw> renanrodrigo: apt policy cloud-init will agree in that case too and represent the  fallback information from dpkg with something like 
[15:13] <blackboxsw>  *** 18.01-0ubuntu3.5 100
[15:13] <blackboxsw>         100 /var/lib/dpkg/status
[15:14] <renanrodrigo> this leads to a question. When package version `X` is released, does package version `X-1` get wiped out from the archives?
[15:14] <blackboxsw> I can see this behavior launching bionic images, yet with the packages: ['landscape-common', 'libpython3.6', 'libpython3.6-minimal', 'libpython3.6-stdlib', 'python3-twisted', 'python3-twisted-bin', 'python3.6', 'python3.6-minimal', 'rsync']
[15:15] <blackboxsw> I happen to know that landscape-common just went through an SRU recently... so there is drift in what the archive represents vs what cloudimage was built with.
[15:17] <renanrodrigo> furthermore, can I assume that those packages that don't have archive references anymore will always have the reference to a newer version?
[15:18] <blackboxsw> renanrodrigo: note as well I can confirm that lxc launch ubuntu-daily:bionic if I hit apt.Cache() before running apt update. You will properly see all packages with correct origins.
[15:18] <blackboxsw> so this drift will always happen on systems that run apt update daily, but to not auto-upgrade packages
[15:19] <blackboxsw> *do not allow unattended upgrades*
[15:19] <MrMobius> im running ubuntu server with no GUI on a low powered netbook. any recommendation for advising me when the battery is low? i know how to check it from the console but cant think of a good way to have it warn me when it's almost dead
[15:20] <blackboxsw> renanrodrigo: "can I assume that those packages that don't have archive references anymore will always have the reference to a newer version?" I don't think always. it's possible someone removed an apt source between updates. So they'd also fall into this camp where no additional newer versions would be visible
[15:22] <renanrodrigo> this makes a tricky situation out of it. If you installed  a package from the archive, and then removed the source, the package holds no information of where it was installed from
[15:22] <sdeziel> MrMobius: I'd try to put that in a cron: read -r capacity < /sys/class/power_supply/BAT0/capacity && [ "$capacity" -lt 20 ] && echo "low battery"
[15:22] <blackboxsw> renanrodrigo: but at that point, those packages would be considered custom local installed debs and so you aren't going to have the ability to upgrade anyway and they wouldn't be in your "list of available updates"
[15:23] <MrMobius> sdeziel, right though you now have random text spurted out somewhere that hopefully you see if youre in a TUI like gdb. i know that will work but was hoping for something less janky
[15:24] <renanrodrigo> blackboxsw: I mean, 'list of available updates' is fine, but how about 'list of installed packages'?
[15:24] <renanrodrigo> if a package is installed from `universe`, and then the source is removed, I have no way to tell it, but this still makes it that you have a `universe` package in your system
[15:24] <sdeziel> MrMobius: actually, this one will produce less noise: read -r capacity < /sys/class/power_supply/BAT0/capacity && [ "$capacity" -gt 20 ] || echo "low battery"
[15:24] <sdeziel> MrMobius: cron's output is emailed normally
[15:25] <sdeziel> MrMobius: that's the quick and dirty way, you are free to replace the echo with something fancy like a webhook or whatever ;)
[15:25] <blackboxsw> renanrodrigo: yes, but APT won't know that anymore for sure because it doesn't have a cache of information anymore to look it up. This is an acceptable scenario for the tooling I would think. If you don't have configuration that tells you where a pkg came from, we can't expect local tooling to report that metadata.
[15:26] <MrMobius> sdeziel, thanks for your help. what im asking basically is what fancy alternatives there are to just printing text at a random place on the screen since you have no control where it ends up if youre in a curses program or something. if cron emails me, can i notify myself some other way?
[15:28] <blackboxsw> renanrodrigo: otherwise `ua security-status` would have to make remote GETs to any expected default APT pockets/components/repos in order to discern if a package version maybe came from said repo/pocket/suite
[15:28] <MrMobius> maybe detach myself from tmux before printing the battery warning and just always stay in tmux
[15:29] <sdeziel> MrMobius: I don't understand whey tmux comes in. cron's could run the above script in its own environment, not inside your tmux
[15:29] <sdeziel> s/whey/where/
[15:30] <renanrodrigo> blackboxsw: I hope we are not doing it :D
[15:31] <renanrodrigo> blackboxsw: so I can assume that a) if I know it from the installed version, we good; b) if i don't, I can go for candidates to know; c) If no candidates, I assume it's third party
[15:31] <MrMobius> sdeziel, what i mean is if im in tmux (or out of tmux for that matter) using gdb or vim and that cron fires, the battery warning could end up anywhere on the screen. if i have the cron job detach me from tmux (not sure if thats possible) then the battery warning will be very noticeable because im suddenly out of vim and at a command prompt
[15:33] <rbasak> MrMobius: you can arrange for tmux to give you a status line with stuff like battery level. Try "byobu" (as a tmux wrapper) for an example.
[15:40] <MrMobius> rbasak, thanks
[15:41] <blackboxsw> renanrodrigo: maybe other folks know if there is vestigial APT/dpkg configuration left on the system after the removal of an apt source and whether you can determine what component if was installed from.  But basically that metadata comes from the Packages file for a given APT repo stored in something /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_bionic-updates_main_binary-amd64_Packages.
[15:43] <blackboxsw> renanrodrigo: one that apt source metadata changes (typical in Ubuntu Packages files to only represent the latest released version) or disappears (due to removal of apt source directive). Then we locally no longer know via apt policy/cache otherwise where debs came from I don't think. Anyone please correct this if I am mistaken.
[15:44] <rbasak> blackboxsw: I'm not sure if I follow your issue exactly, but I'm fairly sure that apt keeps no record of where a package came from. Once it's installed, apt only knows it's installed because dpkg says it is.
[15:45] <rbasak> Apart from logs, and there's the apt-mark thing but I don't think that's relevant to this.
[15:45] <renanrodrigo> rbasak: thanks for clarifying
[15:51] <renanrodrigo> blackboxsw: another tricky situation now - package version `x` is in the archive (in `main`, for instance), but installed version is `x~y.z~ppa234`. How do we list it? Is it main? Is it third party?
[15:55] <blackboxsw> rbasak: thanks, you understand enough of the context. It's trying to accurately represent packages installed on a system and what APT components they originated from via `ua security-status` which talks to python's apt.Cache(). If there is no APT metadata left to /var/lib/apt/lists/*_(Packages|InRelease) tell apt tooling where the package originated, local tools are out of luck.
[15:56] <blackboxsw> renanrodrigo: I'd vote third-party. no telling what patches could have been applied
[15:56] <jrwren> so apt doesn't let you say install at least this version... which would be nice in a dockerfile if you know previous versions have a security vulnerability
[15:56] <jrwren> does dpkg have a way to assert that a version is newer?
[15:56] <jrwren> dpkg --validate-version maybe? but I'm not sure how to use it.
[16:01] <rbasak> blackboxsw: I think the best you can do is match against the installed package version. In theory there should always be a unique version for a unique origin. But in practice third parties break that all the time, and there's little coordination even within "official" sources like ESM.
[16:01] <blackboxsw> jrwren: I'm not quite sure what you are looking for, but if you know the fixed_version "1.2"  and the current_version installed "1.1" you can compare with something like `dpkg --compare-versions  1.1 gt 1.2 && echo "SECURE" || echo "INSECURE"`
[16:02] <blackboxsw> rbasak: +1
[16:02] <rbasak> jrwren: maybe you want "apt satisfy"?
[16:03] <renanrodrigo> rbasak: the problem with this approach is those packages that have stale versions installed, which are not third-parties but rather versions previously in the archives, but now don't have a pointer there anymore.
[16:03] <renanrodrigo> What would we consider those?
[16:04] <rbasak> renanrodrigo: if I follow, then I think what I'm saying is that you need external data to see all the package versions historically published and their origins. Then you could look up everything installed locally to infer (as best as is possible heuristically like that) their origin
[16:05] <rbasak> renanrodrigo: however it's not possible to do that from apt sources or information only available locally
[16:05] <renanrodrigo> rbasak: ack
[16:05] <blackboxsw> rbasak: apt satisfy, nice reference. TIL as I hadn't been aware of it.
[16:09] <rbasak> I think it's relatively new
[16:09] <jrwren> I think apt satisy is what i want. TY.
[16:11] <jrwren> hrm, but it isn't in 18.04 :(
[16:13] <rbasak> I think sbuild uses "equivs" (and "equivs-build", etc) to hack an equivalent
[16:13] <rbasak> Install an equivs package with the versioned dependency relationships you want, and then that'll result in failure, and then ask apt to fix the situation.
[16:15] <jrwren> dpkg --compare-versions $(dpkg -s openssl |awk -F': ' '/^Version/{print $2}') ge 1.1.1-1ubuntu2.1~18.04.15 does exactly what I want. Thank you all.
[16:43] <blackboxsw> good to hear jrwren : You might be able to replace your dpkg -s...  with "$(dpkg-query -Wf='${Version}' openssl)"
[16:44] <blackboxsw> but "6 in one hand half-dozen in the other" or whatever the saying is
[16:50] <rbasak> jrwren: it might be worth noting that there probably exist packages with higher versions that are vulnerable - for example if a subsequent release came out before the security update in a previous release did. But it's probably good enough for you to have what you do.
[17:14] <MrMobius> I can't get this netbook to recognize alt+up or ctrl+up. both of them show ^[[A the same as up in cat. ctrl+letter does work. any idea what's going on?
[18:15] <sergiodj> athos: I closed the 21.04 and 21.10 channels of our snaps
[18:15] <sergiodj> I will wait until Jammy is released to close the 20.04 channels, just in case
[18:28] <athos> sergiodj: thanks! :)
[18:28] <sergiodj> athos: thanks for bringing this up!
[18:35] <bryceh> heh, the update-excuses page is long enough to occasionally cause a firefox tab crash
[19:58] <ahasenack> bryceh: do you know if we have some 22.04-only server guide changes? A pattern?
[19:58] <ahasenack> we decided to use just one guide for all versions, right, and highlight there something was 22.04 specific
[19:58] <bryceh> ahasenack, correct
[19:59] <bryceh> afaik we did not identify a standardized style for calling these out
[19:59] <bryceh> so if you come up with a good approach post about it to the ML
[19:59] <ahasenack> k
[21:25] <kanashiro> in case someone has some time before EOW, I'd like an ack on this debdiff before uploading it: https://bugs.launchpad.net/ubuntu/+source/golang-1.16/+bug/1967425
[21:25] <ubottu> Launchpad bug 1967425 in golang-1.16 (Ubuntu Bionic) "Backport golang 1.16 to Bionic" [Undecided, New]
[21:29] <bryceh> kanashiro, heya I can take a look
[21:29] <bryceh> kanashiro, would you prefer comments here, on the bug, or pm, or ?
[21:30] <kanashiro> bryceh, I think on the bug is fine
[21:30] <bryceh> okie
[21:30] <kanashiro> I am EOWing now, I'll take a look at your comments on Monday :)
[21:30] <bryceh> kanashiro, have a good weekend
[21:31] <kanashiro> bryceh, same for you
[21:31]  * kanashiro -> EOW