[systemd-devel] Why are core dumps named vgcore.*?

[Ulrich Windl]

Hi!

I'm developing a program that dumps core on some failed assertions. I noticed 
that the core dumps are created in the user directory as vgcore.. Where 
does the name vgcore come from?
And is it OK to remove just those files, or does coredumpctl store additional 
infos?

Regards,
Ulrich



___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] What is the recommended way of announcing a TCP port?

[Mantas Mikulėnas]

If you only care about processes on the same system – why not put the
actual socket in /run, as an AF_UNIX socket? That's mostly what /run is for.

On Tue, Jun 15, 2021, 04:18 John Ioannidis  wrote:

> I have an instanced service that gets started and stopped by another
> service: *alice.service *runs the equivalent of *systemsctl start
> alice@foo.service, systemctl start alice@bar.service, systemctl stop
> alice@cat.service*, and so on.
> Each of the instanced services runs a little http service so its status
> can be monitored, metrics scraped, etc. The tcp port on which that service
> runs is just whatever the kernel allocated. I want to export that port
> number so other processes can find it and use it, for example, by doing the
> equivalent of *systemctl list-units | grep alice@ *so they find which
> instances are actually running, and then going about finding the
> corresponding ports.
>
> I can think of a number of ad hoc ways:
>
> * they can write the port number in a file like /run/alice/foo.port,
> /run/alice/bar.port, and whoever is interested can go read those files, in
> the same way that we use .pid files.
> * They can use systemd-notify to export it as "Status"
> * Using a service discovery mechanism would be an overkill, especially
> since whatever is actually talking to those ports is on the same host as
> the services themselves, but that's also a possibility.
>
> Is there a systemd-native way of accomplishing this? It would be nice if
> it were possible to have user-defined properties that could be set with 
> *systemctl
> set-property*, but that is not the case.
>
> Thanks
>
> /ji
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] What is the recommended way of announcing a TCP port?

[Kevin P. Fleming]

You might consider having systemd itself create the listening sockets
and then pass them into the service; if you did that, then systemd
would already know the port number that was allocated for the socket.

On Mon, Jun 14, 2021 at 9:17 PM John Ioannidis  wrote:
>
> I have an instanced service that gets started and stopped by another service: 
> alice.service runs the equivalent of systemsctl start alice@foo.service, 
> systemctl start alice@bar.service, systemctl stop alice@cat.service, and so 
> on.
> Each of the instanced services runs a little http service so its status can 
> be monitored, metrics scraped, etc. The tcp port on which that service runs 
> is just whatever the kernel allocated. I want to export that port number so 
> other processes can find it and use it, for example, by doing the equivalent 
> of systemctl list-units | grep alice@ so they find which instances are 
> actually running, and then going about finding the corresponding ports.
>
> I can think of a number of ad hoc ways:
>
> * they can write the port number in a file like /run/alice/foo.port, 
> /run/alice/bar.port, and whoever is interested can go read those files, in 
> the same way that we use .pid files.
> * They can use systemd-notify to export it as "Status"
> * Using a service discovery mechanism would be an overkill, especially since 
> whatever is actually talking to those ports is on the same host as the 
> services themselves, but that's also a possibility.
>
> Is there a systemd-native way of accomplishing this? It would be nice if it 
> were possible to have user-defined properties that could be set with 
> systemctl set-property, but that is not the case.
>
> Thanks
>
> /ji
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] What is the recommended way of announcing a TCP port?

[John Ioannidis]

I have an instanced service that gets started and stopped by another
service: *alice.service *runs the equivalent of *systemsctl start
alice@foo.service, systemctl start alice@bar.service, systemctl stop
alice@cat.service*, and so on.
Each of the instanced services runs a little http service so its status can
be monitored, metrics scraped, etc. The tcp port on which that service runs
is just whatever the kernel allocated. I want to export that port number so
other processes can find it and use it, for example, by doing the
equivalent of *systemctl list-units | grep alice@ *so they find which
instances are actually running, and then going about finding the
corresponding ports.

I can think of a number of ad hoc ways:

* they can write the port number in a file like /run/alice/foo.port,
/run/alice/bar.port, and whoever is interested can go read those files, in
the same way that we use .pid files.
* They can use systemd-notify to export it as "Status"
* Using a service discovery mechanism would be an overkill, especially
since whatever is actually talking to those ports is on the same host as
the services themselves, but that's also a possibility.

Is there a systemd-native way of accomplishing this? It would be nice if it
were possible to have user-defined properties that could be set with *systemctl
set-property*, but that is not the case.

Thanks

/ji
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Running systemd unprivileged in Docker container

[Daniel Walsh]

On 6/14/21 08:20, Lennart Poettering wrote:

On Fr, 11.06.21 16:55, Johannes Ernst (johannes.er...@gmail.com) wrote:


I can run a full Arch system (with systemd as PID 1) in a Docker container in 
Docker privileged mode:
 sudo docker run -i -t --privileged archlinux /usr/lib/systemd/systemd
but privileged mode is, well, a bit privileged. I believe used to be
 able to tone this down with something like:

So, Docker has an upstream that is pretty hostile towards systemd. As
result, while pretty much all other container managers mostly just
work with systemd as payload, Docker does not.

We document extensively what expectations we have on a container
manager for things to just work:

https://systemd.io/CONTAINER_INTERFACE

The requirements aren't crazy, the few requirements of the above you
really need shold be pretty common sense, yet Docker isn't interested.

My recommendation would be to pick an alternative container manager
with a less hostile upstream. e.g. podman is supposedly a drop-in
replacement and should just work.

If you want to use Docker anyway, I figure you have to make sure you
boot in cgroupsv1 mode (last time I looked the cgroupsv2 support in
Docker wasn't really more than an experiment), and stick to that. Make
sure that cgroupns is enabled, and that /sys/fs/cgroup/ is a tmpfs,
and /sys/fs/cgroup/systemd a cgroupfs mount of the top of the cgroup
namespace the container runs in, and that it is writable.

Not sure how to configure that with Docker, as I am not a Docker
person. Ideally this would be the default setup of Docker, but well,
apparently it isn't.

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Just try it with Podman and see if it works.


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Running systemd unprivileged in Docker container

[Lennart Poettering]

On Fr, 11.06.21 16:55, Johannes Ernst (johannes.er...@gmail.com) wrote:

> I can run a full Arch system (with systemd as PID 1) in a Docker container in 
> Docker privileged mode:
> sudo docker run -i -t --privileged archlinux /usr/lib/systemd/systemd
> but privileged mode is, well, a bit privileged. I believe used to be
> able to tone this down with something like:

So, Docker has an upstream that is pretty hostile towards systemd. As
result, while pretty much all other container managers mostly just
work with systemd as payload, Docker does not.

We document extensively what expectations we have on a container
manager for things to just work:

https://systemd.io/CONTAINER_INTERFACE

The requirements aren't crazy, the few requirements of the above you
really need shold be pretty common sense, yet Docker isn't interested.

My recommendation would be to pick an alternative container manager
with a less hostile upstream. e.g. podman is supposedly a drop-in
replacement and should just work.

If you want to use Docker anyway, I figure you have to make sure you
boot in cgroupsv1 mode (last time I looked the cgroupsv2 support in
Docker wasn't really more than an experiment), and stick to that. Make
sure that cgroupns is enabled, and that /sys/fs/cgroup/ is a tmpfs,
and /sys/fs/cgroup/systemd a cgroupfs mount of the top of the cgroup
namespace the container runs in, and that it is writable.

Not sure how to configure that with Docker, as I am not a Docker
person. Ideally this would be the default setup of Docker, but well,
apparently it isn't.

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Alais for SMTP providers

[Lennart Poettering]

On Sa, 12.06.21 03:33, Kenneth Porter (sh...@sewingwitch.com) wrote:

> I just finished adding a custom service to send an email on system
> shutdown/startup, based on this article:
>
> 
>
> I ended up coding an After for postfix.service so the mail would get get
> delivered before the system shut down. I'd like to be able to use the same
> unit file on older systems that use sendmail, and I know there are other
> packages that provide SMTP and local mail. So it would be desirable to have
> an Alias for those services. I'm using CentOS 8 (7 on older systems). Is
> this perhaps already present in a newer commit? Is there a registry for
> well-known aliases for package writers?

You mean a generic target or so that generically encapsulates "mail
server is up"?

We have no such target upstream, and I am not sure we should add
that. Maybe your downstream distro has that though.

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd.socket man pages update suggestion

[Lennart Poettering]

On Do, 10.06.21 13:44, Ted Toth (txt...@gmail.com) wrote:

>  SELinuxContextFromNet=
>Takes a boolean argument. When true, systemd will attempt to
>figure out the SELinux label used for the instantiated
>service from the information handed by the peer over the
>network. Note that only the security level is used from the
>information provided by the peer. Other parts of the
>resulting SELinux context originate from either the target
>binary that is effectively triggered by socket unit or from
>the value of the SELinuxContext= option. This configuration
>option only affects sockets with Accept= mode set to "yes".
>Also note that this option is useful only when MLS/MCS
>SELinux policy is deployed. Defaults to "false".
>
> Add:
> One or more of the associated service files
> StandardInput/StandardOutput/StandardError options should be set to
> socket for this option to work.
>
> >From execute.c:
>   if (context->std_input == EXEC_INPUT_SOCKET ||
> context->std_output == EXEC_OUTPUT_SOCKET ||
> context->std_error == EXEC_OUTPUT_SOCKET) {
>
> if (params->n_fds != 1) {
> log_unit_error(params->unit_id, "Got more than
> one socket.");
> return -EINVAL;
> }
>
> socket_fd = params->fds[0];
> } else {
> socket_fd = -1;
> fds = params->fds;
> n_fds = params->n_fds;
> }
>
> When socket_fd is -1 the SELinux context is not computed. Text like
> this would have saved a lot of head scratching and code reading :(

We should probably make this work for any service that is instantiated
with a single fd. Can you file a bug on github asking for this?

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Antw: Re: Antw: [EXT] Block systemd from adding new services

[Ulrich Windl]

>>> Andy Pieters  schrieb am 14.06.2021 um 10:09 in
Nachricht
:
> On Mon, 14 Jun 2021 at 09:05, Ulrich Windl <
> ulrich.wi...@rz.uni-regensburg.de> wrote:
> 
>>
>> The better solution would have been to pick a stronger password IMHO.
>>
>>
>> Or rather turn off password authentication. If you must have automation,
> use RSA keys, if not, and really want to keep passwords, add a 2FA to it,
> like yubikey.

Considering a more than 10 year old recommendation that a password should have 
at least 96 bits of entropy, I wonder which robot was able to brute-force 
attack such over SSH.
What passwords and RSA keys have in common: They are worthless once leaked.

Regards,
Ulrich






___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Antw: [EXT] Block systemd from adding new services

[Andy Pieters]

On Mon, 14 Jun 2021 at 09:05, Ulrich Windl <
ulrich.wi...@rz.uni-regensburg.de> wrote:

>
> The better solution would have been to pick a stronger password IMHO.
>
>
> Or rather turn off password authentication. If you must have automation,
use RSA keys, if not, and really want to keep passwords, add a 2FA to it,
like yubikey.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Are Pathnames in /tmp/systemd-private-foo predictable?

[Marc Haber]

On Mon, Jun 14, 2021 at 09:59:24AM +0200, Lennart Poettering wrote:
> It's the boot ID, i.e. /proc/sys/kernel/random/boot_id. We include it
> in the name so that we can distinguish such dirs of the current boot
> from those of earlier boots (which can be retained because of abnormal
> shutdown or so). In the latter case we can safely remove them to avoid
> collecting left-over directories.

Thanks for the explanation, I appreciate that.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Antw: [EXT] Block systemd from adding new services

[Ulrich Windl]

>>> Saint Michael  schrieb am 13.06.2021 um 15:32 in 
>>> Nachricht
:
> One of the most dramatic hacks to 50+ servers of mine is a bitcoin miner,
> xmrig. It installs a service file at /etc/systemd/system, enables it and
> kills the machine.
> Nobody knows how it propagates. I think that SSHD has been broken in a
> foreign land or they just brute-force any machine where
> passwordautorization=yes.
> The point is, for this list, how can I prevent systemd from adding ANY new
> service at all. I am thinking to add chattr +i to /etc/systemd/system, but
> want to know if this makes any sense or if there is a better way to do this.

The better solution would have been to pick a stronger password IMHO.

> Philip




___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Are Pathnames in /tmp/systemd-private-foo predictable?

[Lennart Poettering]

On So, 13.06.21 21:04, Marc Haber (mh+systemd-de...@zugschlus.de) wrote:

> Hi,
>
> I am wondering where the 32 xdigit number in pathnames like
>
> systemd-private-27aa635a15cf4da0a7ebda10f25c3950-chrony.service-9DShFi/
>
> comes from. I always had the impression that it's the systemd/dbus
> machine id, but that does not seem to be the case. Is that just an
> arbitrary random number, or can it be predicted in a way?

It's the boot ID, i.e. /proc/sys/kernel/random/boot_id. We include it
in the name so that we can distinguish such dirs of the current boot
from those of earlier boots (which can be retained because of abnormal
shutdown or so). In the latter case we can safely remove them to avoid
collecting left-over directories.

The dirs are not predictable in their name. The 6 char suffix you see
is the mkstemp() randomized suffix to make them safe against collision
attacks.

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel