| bgstack15 | I have an interesting situation (not a bug, per se). My (ldap) user account, when logging into a Devuan Ceres system, states Warning: your password will expire in 32765 days. | 02:23 |
|---|---|---|
| bgstack15 | This number is higher than my /etc/login.dfs PASS_WARN_AGE. | 02:24 |
| bgstack15 | /etc/login.defs | 02:24 |
| bgstack15 | So why am I seeing this message? Is anyone else seeing anything like that? | 02:24 |
| mason | That particular number feels like an implementation error with systems not agreeing on a field size. | 02:28 |
| bgstack15 | My CentOS (7, and 8) systems do not throw this warning. | 02:28 |
| bgstack15 | Same effect as seen in https://bugzilla.redhat.com/show_bug.cgi?id=1887077 | 02:33 |
| mason | I didn't work on this one, but I saw an error similar to that that was caught a few weeks ago, in newish RHEL 8. So they exist. Not sure in this case... You're probably well-advised to grab an strace and a pcap concurrently from both ends so you can see just what's happening. | 02:33 |
| mason | Oh, that's a useful find then. | 02:34 |
| mason | Probably worth opening an equivalent against Debian. | 02:34 |
| bgstack15 | Oh, I'm still early enough. For all I know my sssd (on all systems) borked. | 02:35 |
| onefang | 32765 days is plenty of time, no need to do anything this early. Wait several decades. B-) | 02:36 |
| mason | bgstack15: That's awfully specific to assume a config issue. Sounds like the same bug. | 02:36 |
| bgstack15 | onefang: lol. Actually my freeipa password policy has a maximum number of much lower than 32765 days. | 02:37 |
| bgstack15 | Hm, I updated libpam-modules from 1.3.1-5 to 1.4.0-2, and the Fedora problem was reported solved in their 1.4.0-6.fc33. | 02:55 |
| bgstack15 | So it's probably a bug in pam 1.4.0 that was fixed with a Fedora patch. Yeah, this definitely looks like something I'll need to send to Debian. Or at least I can narrow down package names to search for recent bugs. | 02:56 |
| mason | There's a request in main asking where the pkginfo source lives, and it's not immediately popping out at me... Is it up on git.devuan.org somewhere? | 14:28 |
| bgstack15 | I am not directly familiar with pkginfo. Is that like pkg-config? | 14:51 |
| mason | bgstack15: https://pkginfo.devuan.org/ | 14:52 |
| bgstack15 | What's the preferred process for making subdirs under /var/run, at boot, without using you-know-what? | 16:36 |
| mason | bgstack15: Presumably the process that needs it will create it before dropping root. | 16:48 |
| bgstack15 | Say, an init script? | 16:49 |
| bgstack15 | for my process in question? | 16:49 |
| mason | An init script could do it. If the daemon itself doesn't do it, consider start-stop-daemon(8) and its --make-pidfile option. | 16:51 |
| bgstack15 | Yeah, I was having trouble with that. | 17:07 |
| bgstack15 | But also I sometimes need to run the daemon directly and not with init. | 17:07 |
| bgstack15 | Ah, yes, so uwsgi_python39 (since apparently uwsgi_python3 just disappeared this last month) can control its own pid... | 17:08 |
| bgstack15 | but not if it's in /var/run/$NAME and that directory doesn't exist yet and is writable by the service account. | 17:09 |
| bgstack15 | *pidfile | 17:09 |
| mason | pidfiles writeable by the account driving the running daemon are a security risk | 17:13 |
| mason | (The --pidfile description in start-stop-daemon(8) speaks to this.) | 17:15 |
| bgstack15 | Oh, OK. Is that mitigated by the pidfile being inside a directory owned by the service account? | 17:19 |
| mason | bgstack15: No, the issue is still that an unprivileged process can direct privileged behaviour. | 17:21 |
| bgstack15 | Ah, so perhaps the best way to accomplish what I want to accomplish is to use an override when my process is being called from an init script, to just let [start-stop-daemon] do all the pidfile work, but when I call my process directly it can do its own pidfile management. | 17:23 |
| mason | What's the difference between calling it directly and via an init script? I'm curious if there's a valid case where you couldn't just use init. | 17:24 |
| bgstack15 | it's on the foreground | 17:27 |
| bgstack15 | mostly | 17:27 |
| mason | ah | 17:27 |
| bgstack15 | because the logging is part of the stuff i'm troubleshooting... | 17:27 |
| mason | Does it need to bother with a pidfile during debugging? | 17:28 |
| mason | Especially in the foreground...? | 17:28 |
| bgstack15 | I'm trying to write something new that could be used either by hand, or in an init script, or any other way a new wsgi app could be used. | 17:29 |
| bgstack15 | It would be nice for the non-init-script method to also include a pidfile ability | 17:29 |
| bgstack15 | uwsgi (_python39?) has the ability to manage its own pidfile which is really the easiest way to safely kill it if you happened to daemonize it | 17:30 |
| bgstack15 | it basically does your ps -u $USER -o whatever | awk '{print $2}' | xargs kill | 17:31 |
| bgstack15 | for you | 17:31 |
| bgstack15 | OK, I ended up using two pidfiles, one owned by root and used by the init script. But I also let uwsgi have its own pidfile owned by the service account so it can easily stop its own uwsgi daemon. | 18:06 |
| bgstack15 | Thank you for the guidance, mason! | 18:07 |
| mason | bgstack15: Sure, happy to help if anything I said was of use. | 18:08 |
| bgstack15 | Yes. I like that you share the relevant safety considerations so that I can follow them. | 18:08 |
| bgstack15 | (unless you think of course that uwsgi as $USER with its own pidfile so it can easily stop its own daemon is a security concern, which we haven't addressed yet) | 18:09 |
| mason | This is one of the areas that are more easily handled under systemd, but there aren't many, and it's not portable. | 18:09 |
| bgstack15 | for some reason I thought somebody had spun off the tmpfiles.d action but I was not able to find it after a very brief search. | 18:10 |
| bgstack15 | Maybe I'm getting confused, and it was a small project they had subsumed. | 18:11 |
| mason | I'd be wary of anything that's a standalone hunk of systemd code, personally. We don't want to encourage the hairball. | 18:13 |
| golinux | https://git.devuan.org/devuan/tellpackage | 18:13 |
| mason | golinux: ty | 18:14 |
| golinux | I had a hard time finding myself. | 18:14 |
| golinux | rrq sometimes finds interesting package names | 18:15 |
| mason | hrh | 18:17 |
| mason | heh* wow and I can't type today | 18:17 |
| golinux | I just noticed that page was last updated on 2021-01-04 17:12:28 UTC while on holiday! | 18:20 |
| mason | heh | 18:20 |
| golinux | I found it by chance from clicking on the "Dashboead" option in git | 18:21 |
| golinux | See I can't type either | 18:22 |
| mason | It's infectious. | 18:22 |
| golinux | You definitely got it from me. | 18:22 |
| onefang | That's why you should wash your hands after typing. Or something. | 18:23 |
| fsmithred | wow, "ALWAYS_SET_PATH y" in /etc/default/su does not fix root's path in chimaera. You now must use "ALWAYS_SET_PATH yes" | 21:07 |
| golinux | Are "they" doing this on purpose just to keep us on our toes? | 22:09 |
| fsmithred | I don't know. I didn't chase down the changelog to see if they mentioned it | 22:10 |
| fsmithred | bgstack15, I can't get orca to read the login screen or the desktop in beowulf, but in an upgrade to chimaera it works without doing anything extra. | 23:38 |
| fsmithred | When I compare running processes when the login screen is up, lightdm has four more processes in chimaera than in beowulf. Three for speech-dispatcher and one for pulseaudio. | 23:39 |
| fsmithred | ok, I just fixed it in beowulf - had to enable pulseaudio autospawn. DOH! | 23:46 |
| golinux | So how do we disbale it and enable it at the same time | 23:47 |
| golinux | ? | 23:47 |
| golinux | Weren't we going to disable it by default? | 23:47 |
| fsmithred | either we or the user only need to do one thing, and that's already described in the release notes. | 23:48 |
| golinux | But the plan was to do it by default in chimaera. Guess that's not going to happen | 23:49 |
| fsmithred | why not? | 23:49 |
| fsmithred | it should certainly be done for the speech install | 23:49 |
| golinux | Does voice synthesis work in Chimaera with autospawn disabled? | 23:50 |
| fsmithred | I'll tell you when I reboot | 23:51 |
| fsmithred | in chimaera, the file has a new name - it's called 01-enable-autospawn.conf and the setting is yes, not commented | 23:54 |
| fsmithred | so user doesn't have to do anything with it | 23:54 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!