=== vlm_ is now known as vlm
=== Napsterbater_ is now known as Napsterbater
=== Napsterbater_ is now known as Napsterbater
[05:59] <icey> thanks ddstreet and rafaeldtinoco :)
[06:41] <lordievader> Good morning
=== antoine5 is now known as antoine
=== Wryhder is now known as Lucas_Gray
[13:11] <icey> hey rbasak - I have a DMB and/or ~ubuntu-server-dev question that I hope you can help with: The OpenStack packaging is all done through the ~ubuntu-server-dev team git repos on Launchpad, for example: https://code.launchpad.net/~ubuntu-server-dev/ubuntu/+source/python-cinderclient/+git/python-cinderclient/ ; After my recent permission change coming through the OpenStack Package Set, I have upload permissions to these packages, but not to the git repos
[13:11] <icey> that back them. Any thoughts on the best way to resolve this?
[13:12] <rbasak> I think we're facing some legacy from when openstack wasn't split out from ~ubuntu-server-dev
[13:12] <rbasak> Since ~ubuntu-server-dev is a DMB-managed uploader team for the entire server packageset
[13:12] <rbasak> Not just the openstack packageset
[13:13] <icey> that's exactly what I think as well
[13:13] <rbasak> I'm not sure if the openstack packageset is supposed to be a subset of the server packageset or individual packages are generally intended to be in only one of them
[13:13] <rbasak> But I don't suppose that matters
[13:13] <rbasak> Now we have ~ubuntu-openstack-dev
[13:14] <icey> rbasak: it's even more awesome, since I don't think most of the OpenStack package set is in the Server package set :-D
[13:14] <rbasak> So maybe we should change the repository owner of all of those repositories over to ~ubuntu-openstack-dev?
[13:14] <rbasak> You'd all need to update your git URLs
[13:14] <rbasak> In any git repositories you have
[13:14] <rbasak> But after that I think you'd be able to continue as normal
[13:14] <icey> yeah - I think each of the packages would need updating for the d/control as well
[13:14] <icey> I'd hold of fon doing that until the package set is up to date as well
[13:14] <rbasak> Right
[13:15] <icey> coreycb: jamespage: thoughts / for awareness
[13:15] <icey> ^
[13:15] <rbasak> ddstreet: ^ FYI
[13:15] <rbasak> Though this is more about git repositories that are mostly outside DMB management
[13:16] <rbasak> icey: when you want to move them, someone who is a member of both can do it from the Launchpad UI I think, and also there's an API method I can help with if you have a big list. All core devs are a member of both teams.
[13:17] <icey> rbasak: I'm sure I can annoy coreycb into handling that :)
[13:17] <icey> rbasak: may be worth doing it via the API as it is probably 150+ packages
[13:17] <coreycb> rbasak: icey: I'm not opposed to moving the repos. I think we could script it and do it early in ubuntu H.
[13:17] <coreycb> or now I guess
[13:17] <icey> coreycb: well, let's hold off until we actually get the packageset up to date (hopefully this week) :-D
[13:18] <coreycb> ok
[13:21] <rbasak> icey: one possible issue. The set of repositories you want to maintain in ~ubuntu-openstack-dev is entirely up to you. Keep a systemd git repository in there if you want for example and nobody will care. Whatever makes sense for you. However the packageset itself that controls uploads is DMB-managed and there might be the odd package (now or in the future) that is "Openstack" to you but "core"
[13:21] <rbasak> elsewhere in Ubuntu or something like that, causing the DMB to avoid putting that in the packageset.
[13:21] <rbasak> The only impact would be to your workflow
[13:22] <icey> rbasak: for sure - some current examples that I'm thinking of are Ceph, openvswitch :-P
[13:22] <rbasak> But in that sense then, if we consider the set of repositories in ~ubuntu-openstack-dev to be independent of the packageset, there's no need to predicate the change over ownership over the packageset update
[13:22] <rbasak> Yeah ceph and openvswitch are blurry
[13:23] <icey> and libvirt, qemu, etc :-D
[13:23] <icey> anyways, that's a different discussion
=== lotuspsychje_ is now known as lotuspsychje
=== RoyK^ is now known as RoyK
[16:37] <jamespage> coreycb, icey I forgot to mention this https://launchpad.net/ubuntu/+source/ceph/15.2.5-0ubuntu1
[16:37] <jamespage> xnox: ^^ has your beast enablement for s390x as well
[16:38] <coreycb> jamespage: great, thanks
=== Wryhder is now known as Lucas_Gray
[17:00] <xnox> whoop whoop
=== powersj_ is now known as powersj
[19:26] <linuxr> hi, anyone using the limits system (/etc/security/limits.conf)? I tried to add a limit for the maximum logins of a user, but seems not to be respected in any way..any ideas?
[19:28] <sarnold> linuxr: do you have pam_limits configured for the services where you want it to be enforced?
[19:32] <linuxr> sarnold, no, is this not by default? how would I do this?
[19:32] <sarnold> linuxr: this can show you which services are configured to use it now: grep -r pam_limits /etc/pam.d
[19:34] <linuxr> sarnold, I see this among others: /etc/pam.d/login:session    required   pam_limits.so
[19:34] <linuxr> doesn't this mean the login restriction as in the limits.conf file should be enforced?
[19:36] <sarnold> linuxr: yes, when the user logs in via the login service -- which is basically 'at the console'
[19:36] <sarnold> linuxr: if the users are logging in via sshd or xdm then those services would also need similar lines
[19:37] <linuxr> sarnold, there's a line for ssh indeed: /etc/pam.d/sshd:session    required     pam_limits.so
[19:37] <sarnold> okay, cool, cool
[19:37] <linuxr> only that is doesnt work :/
[19:40] <linuxr> so any way of debugging this?
[19:42] <sarnold> try running a journalctl -f  in one terminal, then try pushing your ssh connections over the limit for the user in question, and see what gets logged
[19:42] <linuxr> wait - it actually works!
[19:42] <sarnold> I've got a lot of extra audit rules installed that you probably don't have, so your logs will look different from mine, but perhaps seeing mine will give you some idea of what you're seeing..
[19:42] <TJ-> linuxr: add debugging. See "man pam_limits" and the 'debug' option
[19:43] <linuxr> when I try to connect twice from ssh, the second connection gets closed ("too many logins for user")
[19:43] <sarnold> https://paste.ubuntu.com/p/5C7wmJm6V5/
[19:43] <linuxr> but when I have a local session for that user and connect via ssh in addition, the ssh connection is accepted
[19:44] <sarnold> that local session for the user, was that session created with a service that uses pam_limits?
[19:44] <linuxr> sarnold, yes, also within the ssh session of another user
[19:44] <linuxr> not a real local tty
[21:08] <mybalzitch> so how come by 18.04.05 install gets the prompt for 20.04.01 but my 20.04 machine doesn't, lol
[21:08] <mybalzitch> also I can't seem to find the changelog for 20.04.01
[21:10] <sarnold> mybalzitch: https://wiki.ubuntu.com/FocalFossa/ReleaseNotes/ChangeSummary/20.04.1
[21:11] <mybalzitch> argh, thanks sarnold
[21:11] <tomreyn> 20.04 releases wont 'get a prompt', you just install updates and one of them will change the release version number.
[21:11] <mybalzitch> oh okay, that explains that
[21:11] <mybalzitch> thanks you two
[21:12] <sarnold> I'm surprised you got a prompt on your 18.04 system; I thought you weren't going to get one until focal isn't listed in https://changelogs.ubuntu.com/meta-release-development
[21:12] <tomreyn> sarnold: you're looking at "development"
[21:13] <tomreyn> https://changelogs.ubuntu.com/meta-release lists 20.04(.1)
[21:13] <sarnold> tomreyn: that's the thing, I thought that items had to be *removed* from this 'devel' list in order to be promoted, and no longer require the do-release-upgrade -d  switch
[21:13] <tomreyn> oh, not that i know of
[21:15] <tomreyn> i think they need to be *listed* (with "supported: 1"?) in meta-release-lts or meta-release (depending on the "Prompt" setting in /etc/update-manager/release-upgrades )
[21:16] <tomreyn> but this is probably a little underdocumented, so not sure
[21:17] <sarnold> yes, they certainly need to be listed in those files