Luis Gregorio Navarro Rodríguez wrote on 9/25/24 5:22 AM:
>
> Biblical Coventant:
>
> God will not Allow "daemon" name in Linux 7.0 as most as possible.
>
> More Anointing in Linux 7.0 at least.
Thank God he has finally shown
ess=10.140.78.70/28
Gateway=10.140.78.65
DNS=128.196.11.233
DNS=128.196.11.234
DNS=128.196.11.235
LinkLocalAddressing=no
IPv6AcceptRA=no
Best Regards,
Chandler
The University of Arizona block 'A' logo.
*Chandler Sobel-Sorenson*
Sr. Systems Administrator
Arizona Genomics
Lennart Poettering wrote on 12/16/23 7:31 AM:
> Just drop the "--all" from your
> command line.
Unfortunately, there's a stark difference between `systemctl status` and
`systemctl status --all`. For example, the former just prints a tree
layout. It tells me if there are any failures but doesn't
Hi all,
When I run `systemctl status --all` I see a ton of "Unit X could not
be found" where X = an item from the list below. How did this mess
happen and how to clean it up? None of these units represent things the
system is using, for the most part.
Some units appear to be remnants le
e I'll probably be reporting this as an issue looking
for more secure solutions. Thanks again.
Best,
Chandler
/` has a number of files with o+r permission. Not
sure where any leaks could be there besides `environ` file, which does
have `SEC=1234` in it but with restrictive mode 600 on it too.
chandler wrote on 9/26/23 4:39 AM:
> Hi all,
>
> I'm not quite grasping something here... I'
Hi all,
I'm not quite grasping something here... I've just learned about
`systemd-creds` and now trying to utilize it with a service which
depends on a secret stored in an environment variable (or passed as a
CLI option).
Normally I could use a line like:
`Environment=SEC=1234`
Now I've:
1
Mantas Mikulėnas wrote on 4/10/23 10:31 PM:
> The same pam_systemd module registers a "session" with logind (which
> triggers the creation of runtime directory as well as the startup of
> user@.service; note: /not/ user@)
hmmm... it's a bit ambiguous since we use LDAP too. There, "uid" is a
user n
systemd has been working great here, system-wide as well as in all user
instances except one. I'm not exactly sure what all the steps are in
the process to get a systemd user instance running. The directory
/run/user/$UID was not being created, though.
I made some progress by running `systemctl
