Re: [systemd-devel] How to override generators on debian (v215)?

[Mirosław Zalewski]

On Wed, 17 Aug 2016 21:51:27 + 
Zbigniew Jędrzejewski-Szmek  wrote:

> Overriding of generators was added in systemd 219
> (https://github.com/systemd/systemd/commit/e801700e9a). I don't think
> there's an easy solution for older systemds.

In case of Debian stable, one can install systemd 230 from
backports .
-- 
Best regards
Mirosław Zalewski
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to override generators on debian (v215)?

[Zbigniew Jędrzejewski-Szmek]

On Wed, Aug 17, 2016 at 04:02:00PM +, nusenu wrote:
> Hi,
> 
> according to the official documentation from upstream systemd [1] it is
> possible to override a package generator by placing a custom generator
> (with the same name) into  /etc/system/system-generator.
> 
> Since there is no manual page for systemd.generator on debian stable, I
> tried the paths mentioned in the upstream manual.
> 
> I created
> /etc/systemd/system-generators/tor-generator
> to override:
> 
> /lib/systemd/system-generators/tor-generator
> 
> with no effect, the former generator is not executed as expected on
> systemctl daemon-reload
> (the later is).
> 
> I assume systemd in debian stable (v215) is simply to old for this feature?
> When has it been introduced?

Overriding of generators was added in systemd 219
(https://github.com/systemd/systemd/commit/e801700e9a). I don't think there's
an easy solution for older systemds.

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

Re: [systemd-devel] how to encrypt journalctl metadata

[Mantas Mikulėnas]

On Wed, Aug 17, 2016 at 10:10 PM, Divya Thaluru 
wrote:

> Hi,
>
> Journalctl stores metadata like "_UID,_GID,_CMDLINE,_SYSTEMD_CGROUP etc…"
> for each message. Is there any way, can we encrypt metadata (commandline
> info) so sensitive information wont be stored.
>
> If encryption of metadata is not possible, can we disable collecting the
> metadata?
>

Store your logs in a LUKS volume. There's no built-in encryption in
journald.

And... quite frankly, I cannot imagine how service name or its UID would be
more sensitive than the messages themselves? It seems the opposite of every
single system I've seen. The *messages* often contain sensitive
information, whereas PIDs or service names are mostly generic info.

Just set up a LUKS container for /var/log.

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

Re: [systemd-devel] how to encrypt journalctl metadata

[Divya Thaluru]

Thanks Mantas!!! In my case, metadata "cmdline" had sensitive information
which I am not intended to store. Is there any way to disable collecting
metadata?

Thanks,
Divya



On Wed, Aug 17, 2016 at 12:55 PM, Mantas Mikulėnas 
wrote:

> On Wed, Aug 17, 2016 at 10:10 PM, Divya Thaluru 
> wrote:
>
>> Hi,
>>
>> Journalctl stores metadata like "_UID,_GID,_CMDLINE,_SYSTEMD_CGROUP
>> etc…" for each message. Is there any way, can we encrypt metadata
>> (commandline info) so sensitive information wont be stored.
>>
>> If encryption of metadata is not possible, can we disable collecting the
>> metadata?
>>
>
> Store your logs in a LUKS volume. There's no built-in encryption in
> journald.
>
> And... quite frankly, I cannot imagine how service name or its UID would
> be more sensitive than the messages themselves? It seems the opposite of
> every single system I've seen. The *messages* often contain sensitive
> information, whereas PIDs or service names are mostly generic info.
>
> Just set up a LUKS container for /var/log.
>
> --
> Mantas Mikulėnas 
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] how to encrypt journalctl metadata

[Divya Thaluru]

Hi,

Journalctl stores metadata like "_UID,_GID,_CMDLINE,_SYSTEMD_CGROUP etc…"
for each message. Is there any way, can we encrypt metadata (commandline
info) so sensitive information wont be stored.

If encryption of metadata is not possible, can we disable collecting the
metadata?

  _UID=0

_GID=0

_SYSTEMD_SLICE=

_BOOT_ID=

PRIORITY=

_CAP_EFFECTIVE=

_MACHINE_ID=

_TRANSPORT=

SYSLOG_FACILITY=

_SYSTEMD_CGROUP=

_SYSTEMD_UNIT=

_HOSTNAME=

_COMM=

_EXE=

_PID=

_CMDLINE=

*MESSAGE=*

_SOURCE_REALTIME_TIMESTAMP=

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

Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.

[Xen]

Jóhann B. Guðmundsson schreef op 16-08-2016 18:58:


I personally recommend the project should stick with the original line
drew in the sand, for the master branch and all the "experimental"
stuff which may or may not come to pass, be kept in it's own
experimental branch which would be the best of the both worlds I would
think. Downstream that want stability get what they want and are less
likely to experience any sudden *surprises* and those that want the
experimental stuff for whatever reason like testing get what they
want.




Not wanting to barge in here, but it seems to me that your disagreement 
is not necessarily a principle stance, but merely the fact that 
different people have different principle stances that conflict.


And so they conflict and if one party wants upstream to happen first and 
the other party wants downstream to happen first, you are at a 
stalemate. And it is not so much because intermixing seems bad but 
because you have a practical problem which is that some developer 
refuses to do something because it hasn't been upstreamed yet.


This refusal that you considered perfectly reasonable seems the only 
obstacle here for you. And then it becomes a problem if other people do 
not also follow that principle. But instead of making other people more 
strict, I would suggest you focus on making the other party less strict. 
It seems this strictness is the only problem here, instead of the 
solution.


Regards.

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

[systemd-devel] How to override generators on debian (v215)?

[nusenu]

Hi,

according to the official documentation from upstream systemd [1] it is
possible to override a package generator by placing a custom generator
(with the same name) into  /etc/system/system-generator.

Since there is no manual page for systemd.generator on debian stable, I
tried the paths mentioned in the upstream manual.

I created
/etc/systemd/system-generators/tor-generator
to override:

/lib/systemd/system-generators/tor-generator

with no effect, the former generator is not executed as expected on
systemctl daemon-reload
(the later is).

I assume systemd in debian stable (v215) is simply to old for this feature?
When has it been introduced?

Is there another workaround that one could apply?

thanks,
nusenu

[1] https://www.freedesktop.org/software/systemd/man/systemd.generator.html

background:
https://github.com/nusenu/ansible-relayor/issues/72
https://lists.torproject.org/pipermail/tor-relays/2016-August/009874.html




signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel