On Mo, 12.09.22 13:26, Ted Toth ([email protected]) wrote:
> I've been looking at the issue of systemd setting the socket
> activation socket context to init_t when using SELinuxContextFromNet.
> My initial thought was to use the port context set by running semanage
> and compute the socket context
I've been looking at the issue of systemd setting the socket
activation socket context to init_t when using SELinuxContextFromNet.
My initial thought was to use the port context set by running semanage
and compute the socket context using a type transition for the port
type to a socket type. Howeve
I'm testing a runner of a patch but what I'm seeing is
setsockcreatecon called (in a sd-listen process) with the context I've
set using 'semanage port -t' but then when I look at the listening
socket context (netstat -Z) it is still init_t and not the type set by
setsockcreatecon. I'm not clear abo
I think I figured out how to add libsemanage to the link, when you see
the patch you can tell me if I did it right.
On Tue, Sep 6, 2022 at 11:46 AM Ted Toth wrote:
>
> I'm working on a patch and adding a function to selinux_util.c which
> calls libsemanage functions but I don't know how to add th
I'm working on a patch and adding a function to selinux_util.c which
calls libsemanage functions but I don't know how to add this library
to the link of the systemd (libsystemd-shared-.so) shared
library as I'm not familiar with the build, how do I do this?
Also a lot of the semanage functions on f
On Fr, 02.09.22 09:04, Ted Toth ([email protected]) wrote:
> I have set the type for the port in question using the 'semanage port'
> command so the loaded policy has a type which systemd should use when
> calling setsockcreatecon. It is my opinion that
> socket_determine_selinux_label function sho
I have set the type for the port in question using the 'semanage port'
command so the loaded policy has a type which systemd should use when
calling setsockcreatecon. It is my opinion that
socket_determine_selinux_label function should query policy for the
port type and if it has been set use it an
On Do, 25.08.22 14:46, Ted Toth ([email protected]) wrote:
> I've tested setting the type of the port using semanage port -a
> however when I start the service netstat still shows the type as
> init_t. I don't know of any other way to get a type transition of a
> socket to happen, do you?. I've als
I've tested setting the type of the port using semanage port -a
however when I start the service netstat still shows the type as
init_t. I don't know of any other way to get a type transition of a
socket to happen, do you?. I've also posted to the selinux list but
haven't gotten any responses yet.
On Mi, 24.08.22 11:50, Ted Toth ([email protected]) wrote:
> I don't see a way to set the context of the socket that systemd
> listens on. If there is a way to do this please tell me otherwise I'd
> like to see an option (SELinuxCreateContext?) added to be able to set
> the context (setsockcreateco
I don't see a way to set the context of the socket that systemd
listens on. If there is a way to do this please tell me otherwise I'd
like to see an option (SELinuxCreateContext?) added to be able to set
the context (setsockcreatecon) to be used by systemd when creating the
socket. Currently as an
Unfortunately I was using 0.0.0.0 to connect to rsync in the proxy and
the netlabel.rules entry for that ip is unlabeled when I changed the
ip to 127.0.0.1 systemd no longer reports this error.
Ted
On Tue, Jun 8, 2021 at 10:16 AM Ted Toth wrote:
>
> I'm working on a proxy to encrypt rsync networ
I'm working on a proxy to encrypt rsync network communications using
systemd socket activation (Accept=yes, SELinuxContextFromNet=true) so
that the proxy is run at the level of the connection (the system is
running selinux mls policy). rsync has the same systemd socket
activation configuration as I
On Fri, 28 May 2021 at 21:27, Ted Toth wrote:
> When a socket service runs is there a way to determine the socket
> state? If the socket file contains:
> Accept=true
>
> does systemd call accept with the socket before execing the service in
> which case I don't have to call accept?
Yes, with Ac
When a socket service runs is there a way to determine the socket
state? If the socket file contains:
Accept=true
does systemd call accept with the socket before execing the service in
which case I don't have to call accept? Is there a way to
differentiate a socket with Accept set to true versus o
The default mode (Accept=no) expects your daemon to remain running forever
and handle *all* requests in the same instance. Basically once the daemon
is started and receives the listening socket, it continues working like a
traditional daemon would: start an event loop, perhaps use threads or
worker
Hello,
I am adding socket activation to a daemon. It basically works well, but for
multiple simultaneous connections, the systemd seems to serialize the
incoming requests, spawning the daemon for each request only after the
previous request is served (i.e. the daemon terminates).
Is it really the
On Mi, 04.04.18 22:10, Alex Ivanov ([email protected]) wrote:
> Hi.
> I want to use systemd as fastcgi spawner for gitweb + nginx.
> The traffic is low and number of users is limited + traversal bots. For that
> reason I've decided to use following mimimal services
>
> gitweb.socket:
> [Unit]
> De
On Wed, Apr 4, 2018, 22:18 Alex Ivanov wrote:
> Hi.
> I want to use systemd as fastcgi spawner for gitweb + nginx.
> The traffic is low and number of users is limited + traversal bots. For
> that reason I've decided to use following mimimal services
>
> gitweb.socket:
> [Unit]
> Description=GitWe
Hi.
I want to use systemd as fastcgi spawner for gitweb + nginx.
The traffic is low and number of users is limited + traversal bots. For that
reason I've decided to use following mimimal services
gitweb.socket:
[Unit]
Description=GitWeb Socket
[Socket]
ListenStream=/run/gitweb.sock
Accept=false
Hi,
Please see this thread
http://comments.gmane.org/gmane.comp.sysutils.systemd.devel/35437, and for
that usecase, the suggestion to do shutdown did work fine, and with that I
was able to handle this case.
At that time, the other request I had was if sd_pid_notify_with_fds or
equivalent could
On Wed, Feb 24, 2016 at 4:29 AM, Lennart Poettering
wrote:
> On Tue, 23.02.16 14:58, Ben Woodard ([email protected]) wrote:
>
> > On Thu, Feb 18, 2016 at 9:08 AM, Lennart Poettering <
> [email protected]>
> > wrote:
> >
> > > On Wed, 17.02.16 17:44, Ben Woodard ([email protected]) wrote:
>
On Tue, 23.02.16 14:58, Ben Woodard ([email protected]) wrote:
> On Thu, Feb 18, 2016 at 9:08 AM, Lennart Poettering
> wrote:
>
> > On Wed, 17.02.16 17:44, Ben Woodard ([email protected]) wrote:
> >
> > > Is it intentional that systemd holds a reference to a socket it has
> > > just accepted e
On Thu, Feb 18, 2016 at 9:08 AM, Lennart Poettering
wrote:
> On Wed, 17.02.16 17:44, Ben Woodard ([email protected]) wrote:
>
> > Is it intentional that systemd holds a reference to a socket it has
> > just accepted even though it just handed the open socket over to a
> > socket.activated servic
On Wed, 17.02.16 17:44, Ben Woodard ([email protected]) wrote:
> Is it intentional that systemd holds a reference to a socket it has
> just accepted even though it just handed the open socket over to a
> socket.activated service that it has just started.
Yes, we do that currently. While there's
> On Feb 18, 2016, at 4:23 AM, Zbigniew Jędrzejewski-Szmek
> wrote:
>
> On Thu, Feb 18, 2016 at 09:59:32AM +0300, Andrei Borzenkov wrote:
>> On Thu, Feb 18, 2016 at 4:44 AM, Ben Woodard wrote:
>>> Is it intentional that systemd holds a reference to a socket it has just
>>> accepted even thoug
On Thu, Feb 18, 2016 at 09:59:32AM +0300, Andrei Borzenkov wrote:
> On Thu, Feb 18, 2016 at 4:44 AM, Ben Woodard wrote:
> > Is it intentional that systemd holds a reference to a socket it has just
> > accepted even though it just handed the open socket over to a
> > socket.activated service that
On Thu, Feb 18, 2016 at 4:44 AM, Ben Woodard wrote:
> Is it intentional that systemd holds a reference to a socket it has just
> accepted even though it just handed the open socket over to a
> socket.activated service that it has just started.
yes.
>
> For example given the following unit file
Is it intentional that systemd holds a reference to a socket it has just
accepted even though it just handed the open socket over to a socket.activated
service that it has just started.
For example given the following unit files:
/etc/systemd/system/test.socket:
[Unit]
Description=test service
On Mon, 20.04.15 14:15, Spencer Baugh ([email protected]) wrote:
> Lennart Poettering writes:
> > On Mon, 20.04.15 13:01, Spencer Baugh ([email protected]) wrote:
> >> Lennart Poettering writes:
> >> > Hmm, so you say the initial connection does not work but triggers the
> >> > container, but th
Lennart Poettering writes:
> On Mon, 20.04.15 13:01, Spencer Baugh ([email protected]) wrote:
>> Lennart Poettering writes:
>> > Hmm, so you say the initial connection does not work but triggers the
>> > container, but the subsequent one will?
>>
>> Not quite; the initial connection seems to act
On Fri, 17.04.15 23:27, [email protected] ([email protected]) wrote:
> Hi,
>
> I am having trouble with socket-activated containers, where the socket
> is first opened outside the container, on an interface/IP address that
> is then passed in to the container.
>
> In short, when I try to ssh to
--text follows this line--
Hi,
I am having trouble with socket-activated containers, where the socket
is first opened outside the container, on an interface/IP address that
is then passed in to the container.
In short, when I try to ssh to the IP address of the container, the
container is indeed
Hello All.
Just a short heads-up. Xserver from Xorg has gained support for socket
activation.
http://cgit.freedesktop.org/xorg/xserver/commit/?id=b3d3ffd19937827bcbdb833a628f9b1814a6e189
http://cgit.freedesktop.org/xorg/lib/libxtrans/commit/?id=e1e6121a1638d43d9929589b4723da2b38cb6b44
http://cgit
On Thu, 20.06.13 09:31, Colin Guthrie ([email protected]) wrote:
> As is uses the dbus alias, I guess the intention is that it only works
> when the service is enabled in systemd. Without the service being
> enabled, the alias does not exist and thus it cannot be bus activated.
Correct.
> I g
On Thu, Jun 20, 2013 at 5:00 PM, Michael Biebl wrote:
> 2013/6/20 Colin Guthrie :
>> I presume that to have "bus activation by default", the only change
>> needed would be to change the dbus .service file for modem manager to
>> refer to the SystemdService via it's normal name and not via it's bus
2013/6/20 Colin Guthrie :
> I presume that to have "bus activation by default", the only change
> needed would be to change the dbus .service file for modem manager to
> refer to the SystemdService via it's normal name and not via it's bus
> alias? Is this the "expected" way to work.
The relevant
'Twas brillig, and Colin Guthrie at 20/06/13 09:31 did gyre and gimble:
> Now for NetworkManager itself this more or less OK. You'll be needing it
> pretty much immediately on boot anyway, but what's caught me out a
> little bit more is that ModemManager (0.7.991) also follows this same
> pattern.
Hi,
Leading on from the "Masking socket activated..." thread recently, I was
thinking a bit about some of the units in Network Manager.
Network Manager 0.9.8.0 contains the following NetworkManager.service unit.
[Unit]
Description=Network Manager
After=syslog.target
Wants=network.target
Before=n
Thanks! I will have a try.
On Thu, 27 Dec 2012 03:38:08 -0800
David Strauss wrote:
> On Mon, Dec 24, 2012 at 7:29 AM, Jian Lin wrote:
> > I want to use systemd to manage some services written in Java.
> > I found it is easy to write service units for starting and stopping
> > the services.
> >
On Mon, Dec 24, 2012 at 7:29 AM, Jian Lin wrote:
> I want to use systemd to manage some services written in Java.
> I found it is easy to write service units for starting and stopping
> the services.
> However, I also hope to implement the socket activation for Java services,
> in order to start t
Hi,
I want to use systemd to manage some services written in Java.
I found it is easy to write service units for starting and stopping
the services.
However, I also hope to implement the socket activation for Java services,
in order to start the service when receiving the first connection.
Should
Here is the initial ticket with implementation:
http://trac.nginx.org/nginx/ticket/237
--
David Strauss
| [email protected]
___
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-
On Fri, 30.03.12 14:48, Ayoub Arfaoui ([email protected]) wrote:
> How to patch a service to be socket-activable ?
http://0pointer.de/blog/projects/socket-activation.html
http://0pointer.de/blog/projects/socket-activation2.html
This is all linked from the systemd homepage BTW.
http://www.free
On Fri, Mar 30, 2012 at 02:48:03PM +0100, Ayoub Arfaoui wrote:
> How to patch a service to be socket-activable ?
http://0pointer.de/blog/projects/socket-activation.html
http://0pointer.de/blog/projects/socket-activation2.html
--
Tomasz TorczTo co nierealne -- tutaj
How to patch a service to be socket-activable ?
___
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
46 matches
Mail list logo
