Re: Bug#756521: ITP: kadeploy -- Scalable, efficient and reliable cluster provisioning solution

[Charles Plessy]

Le Sat, Aug 02, 2014 at 07:22:24AM +0200, Lucas Nussbaum a écrit :
> On 02/08/14 at 09:51 +0800, Paul Wise wrote:
> > 
> > One downside of cloning Debian based images is that debootstrap, dpkg
> > and package maintainer scripts leave system-specific files (like
> > openssh private keys, systemd machine ids, dbus machine ids etc) in
> > the resulting image and you have to workaround that after generating
> > the image.
> > 
> > How does Kadeploy currently deal with this sort of issue?
> 
> There's a post-installation phase where machine-specific files are
> copied to the cloned system.
> 
> > Perhaps we need to merge the Debian cloud/live team's handling of this
> > issue and put that in a package that Kadeploy can use...
> 
> Yes, or at least the Kadeploy developers should take a look at what is
> done there, to make sure that the same things are covered on both sides.

Ideally, the packages providing software using machine-specific keys or IDs,
etc., should provide the functionalities to facilitate the production of
generic machine images.

A straightforward way is exemplified by the case of SSH, where the server keys
are regenerated if they are absent.  It then only takes to delete the keys when
preparing images to avoid the problem of duplicated IDs or privacy leaks.

Following similar ways with other packages when possible will avoid the
proliferation of parallel solutions.

This said, a check list or a checking program for inspecting images and
finding if machine-speficif files are still present would be nice…

Have a nice week-end,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140802070326.ga9...@falafel.plessy.net

Bug#753013: ITP: cppdb -- SQL Connectivity Library

[Tobias Frost]

Package: wnpp
Tags: -1 pending
Followup-For: Bug #753013
Owner: Tobias Frost 

cppdb is now in NEW.

-- 
tobi


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140802075347.11344.47464.report...@edoras.loewenhoehle.ip

more files in /usr/share/doc could possibly be symlinked

[積丹尼 Dan Jacobson]

Perhaps more duplicate files in /usr/share/doc could be symlinked to
save space in some cases, depending on their dependencies...
$ cd /usr/share/doc && ls -ogi */changelog.gz|sort -k 4nr|head
25166091 -rw-r--r-- 1 2606373 07-24 01:11 krb5-locales/changelog.gz
25302407 -rw-r--r-- 1 1944189 07-31 23:47 libvirt-bin/changelog.gz
25302415 -rw-r--r-- 1 1944189 07-31 23:47 libvirt0/changelog.gz
25565662 -rw-r--r-- 1 1944189 07-31 23:47 libvirt-clients/changelog.gz
25565667 -rw-r--r-- 1 1944189 07-31 23:47 libvirt-daemon/changelog.gz
25565671 -rw-r--r-- 1 1944189 07-31 23:47 libvirt-daemon-system/changelog.gz
25297489 -rw-r--r-- 1 1674007 07-17 15:04 xserver-common/changelog.gz
25300435 -rw-r--r-- 1 1674007 07-17 15:04 xserver-xorg-core/changelog.gz
25035737 -rw-r--r-- 1 1120163 06-24 11:01 libglib2.0-0/changelog.gz
25297072 -rw-r--r-- 1 1120163 06-24 11:01 libglib2.0-data/changelog.gz


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87zjfnfens@jidanni.org

Bug#756835: First steps towards source-only uploads

[Charles Plessy]

Package: debian-policy
Severity: wishlist
Version: 3.9.5.0

Le Fri, Aug 01, 2014 at 12:25:05PM +0200, Ansgar Burchardt a écrit :
> On 08/01/2014 12:17, martin f krafft wrote:
> > also sprach Paul Wise  [2014-08-01 11:33 +0200]:
>   * The source package includes a Package-List field that also has
> an arch=* column. dpkg (>= 1.17.7) will include this.
> >>>
> >>> Can we read up more on this somewhere?
> >>
> >> It is the default if you are using dpkg-dev from jessie and you don't
> >> need to do anything other than generating your .dsc with dpkg-source
> >> as per usual.
> > 
> > I want to understand purpose and syntax of this new field.
> 
> The field was originally discussed in https://bugs.debian.org/619131 to
> allow easier processing of packages that build arch-specific binaries
> such as src:linux[1].
> 
> The architecture information was only (re)introduced later, as far as I
> know to help with bootstrapping, but it turns out that I also want this
> for source-only uploads to catch uploads introducing NEW binary packages.

Hi Ansgar, Martin, and Policy Editors,

here is a proposed update for the description of the Package-List field
in the Policy's section 5.6.27.  (patch attached).

For the busy people, here is the current content of §5.6.27–8.

-
5.6.27 Package-List

Multiline field listing all the packages that can be built from the source
package, considering every architecture. The first line of the field value is
empty. Each one of the next lines describes one binary package, by listing its
name, type, section and priority separated by spaces. Fifth and subsequent
space-separated items may be present and parsers must allow them. See the
Package-Type field for a list of package types.

5.6.28 Package-Type

Simple field containing a word indicating the type of package: deb for binary
packages and udeb for micro binary packages. Other types not defined here may
be indicated. In source package control files, the Package-Type field should be
omitted instead of giving it a value of deb, as this value is assumed for
paragraphs lacking this field.
-

Everybody's suggestions are welcome !

Have a nice week-end, and big thank you to Ansgar and the other FTP Masters for
the source-only uploads !

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan
>From b1aa1bf72723e4594557f9898da97afe23f0c900 Mon Sep 17 00:00:00 2001
From: Charles Plessy 
Date: Sat, 2 Aug 2014 19:30:57 +0900
Subject: [PATCH] =?UTF-8?q?Document=20the=20=E2=80=98arch=E2=80=99=20and?=
 =?UTF-8?q?=20=E2=80=98profile=E2=80=99=20options=20in=20the=20Package-Lis?=
 =?UTF-8?q?t=20field.?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 policy.sgml | 8 
 1 file changed, 8 insertions(+)

diff --git a/policy.sgml b/policy.sgml
index ae9d173..33c4f1a 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -3826,6 +3826,14 @@ Checksums-Sha256:
 	Package-Type field for a list of
 	package types.
 	  
+	  
+	The optional fields currently in use add informations related to
+architectures build profiles, with a syntax such as
+name=value1,value2 and names arch and
+profile
+	  They were introduced in dpkg version
+	  1.17.7 in Jessie.
+	  
 	
 
 	
-- 
2.0.1

packages using non-standard ports

[Daniel Pocock]

syslog-nagios-bridge needs to listen on a TCP port for connections from
rsyslogd or whatever


To make it easy for users (fully automated installation), I can

a) configure the package to listen on some port (I use 30514)

b) deploy a file /etc/rsyslog.d/nagios-bridge.conf with the config for
the same port

Doing this, the service starts working as soon as the package is installed.

Do people feel it is a good idea for packages to grab non-standard ports
like this?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53dcc5ed.6060...@pocock.pro

Re: packages using non-standard ports

[Neil Williams]

On Sat, 02 Aug 2014 13:05:17 +0200
Daniel Pocock  wrote:

> 
> 
> 
> syslog-nagios-bridge needs to listen on a TCP port for connections
> from rsyslogd or whatever
> 
> 
> To make it easy for users (fully automated installation), I can
> 
> a) configure the package to listen on some port (I use 30514)
> 
> b) deploy a file /etc/rsyslog.d/nagios-bridge.conf with the config for
> the same port
> 
> Doing this, the service starts working as soon as the package is
> installed.
> 
> Do people feel it is a good idea for packages to grab non-standard
> ports like this?

Do both a) and b) - ensure that if the local admin changes the port
number, things continue working after service restart & reboot.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



signature.asc
Description: PGP signature

Re: packages using non-standard ports

[Ben Hutchings]

On Sat, 2014-08-02 at 13:05 +0200, Daniel Pocock wrote:
> 
> 
> syslog-nagios-bridge needs to listen on a TCP port for connections from
> rsyslogd or whatever
> 
> 
> To make it easy for users (fully automated installation), I can
> 
> a) configure the package to listen on some port (I use 30514)
> 
> b) deploy a file /etc/rsyslog.d/nagios-bridge.conf with the config for
> the same port
> 
> Doing this, the service starts working as soon as the package is installed.
> 
> Do people feel it is a good idea for packages to grab non-standard ports
> like this?

Not really, no.  Isn't there a standard port for this?  (Annoyingly
514/tcp is assigned to a completely different protocol.)

Ben.

-- 
Ben Hutchings
Reality is just a crutch for people who can't handle science fiction.


signature.asc
Description: This is a digitally signed message part

Re: packages using non-standard ports

[Daniel Pocock]

On 02/08/14 15:24, Ben Hutchings wrote:
> On Sat, 2014-08-02 at 13:05 +0200, Daniel Pocock wrote:
>>
>>
>> syslog-nagios-bridge needs to listen on a TCP port for connections from
>> rsyslogd or whatever
>>
>>
>> To make it easy for users (fully automated installation), I can
>>
>> a) configure the package to listen on some port (I use 30514)
>>
>> b) deploy a file /etc/rsyslog.d/nagios-bridge.conf with the config for
>> the same port
>>
>> Doing this, the service starts working as soon as the package is installed.
>>
>> Do people feel it is a good idea for packages to grab non-standard ports
>> like this?
> 
> Not really, no.  Isn't there a standard port for this?  (Annoyingly
> 514/tcp is assigned to a completely different protocol.)
> 


The syslog daemon itself usually listens on 514

It then relays a copy of every message to syslog-nagios-bridge on
localhost:30514 or whatever using the same Syslog protocol.

syslog-nagios-bridge shouldn't run on 514.  Although it can receive
Syslog packets, it doesn't store them to file or database or any other
normal Syslog features.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53dce848.1080...@pocock.pro

Re: Bug#756521: ITP: kadeploy -- Scalable, efficient and reliable cluster provisioning solution

[Simon McVittie]

On 02/08/14 08:03, Charles Plessy wrote:
> A straightforward way is exemplified by the case of SSH, where the server keys
> are regenerated if they are absent.  It then only takes to delete the keys 
> when
> preparing images to avoid the problem of duplicated IDs or privacy leaks.

D-Bus (/var/lib/dbus/machine-id) also regenerates its machine ID during
boot if required, although systemd (/etc/machine-id) is not always able
to do so (because it's pid 1, and our initramfs does not fsck the root
filesystem, systemd typically starts before the root filesystem is
read/write, but it wants to be able to have a machine ID immediately).

As of jessie, each will copy the other's idea of the machine ID if it
exists, or create a new one if not; in wheezy, systemd would copy the
D-Bus machine ID, but D-Bus would create a new ID rather than copying
the one from systemd.

Some component still needs to know that those specific files should be
reset when preparing a generic image, and how to reset them - for
systemd it is actually better to truncate /etc/machine-id than to delete
it, because if it exists as an empty file, systemd can do tricks with
bind-mounts to mount a transient machine-id over the top, copying the
one from dbus if available.

Perhaps it would be good to define a "reset-machine-state" dpkg trigger
or something; then tools like live-build could trigger it, and dbus
could take responsibility for deleting /var/lib/dbus/machine-id when it
is triggered? live-build etc. would have to keep their current hooks for
now.

S


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53dce925.4030...@debian.org

Re: more files in /usr/share/doc could possibly be symlinked

[Simon McVittie]

On 02/08/14 10:01, 積丹尼 Dan Jacobson wrote:
> Perhaps more duplicate files in /usr/share/doc could be symlinked to
> save space in some cases

Yes, I'm sure some of them could; but whenever the infrastructure to do
this goes slightly wrong, it ends up as failure to install (or a missing
file that is required by Policy) and a release-critical bug. So it is
entirely reasonable for a package maintainer to consider this to not be
worthwhile.

If you want to save the space used by identical files, an offline
deduplication process using hardlinks or btrfs reflinks is likely to
work better for you - that doesn't have to respect dependencies, either.

S


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53dcea35.2050...@debian.org

Re: Bug#756521: ITP: kadeploy -- Scalable, efficient and reliable cluster provisioning solution

[Paul Wise]

On Sat, Aug 2, 2014 at 3:03 PM, Charles Plessy wrote:

> A straightforward way is exemplified by the case of SSH, where the server keys
> are regenerated if they are absent.  It then only takes to delete the keys 
> when
> preparing images to avoid the problem of duplicated IDs or privacy leaks.

It seems like a horrible horrible hack to to have to remove
system-specific files after the fact rather than generating a generic
image in the first place.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAKTje6HY0xoNGLh9fvbYXrUFA2c8=9jsb0txm6+nm5bht23...@mail.gmail.com

Re: packages using non-standard ports

[Josh Triplett]

Daniel Pocock wrote:
> syslog-nagios-bridge needs to listen on a TCP port for connections from
> rsyslogd or whatever
> 
> To make it easy for users (fully automated installation), I can
> 
> a) configure the package to listen on some port (I use 30514)
> 
> b) deploy a file /etc/rsyslog.d/nagios-bridge.conf with the config for
> the same port
> 
> Doing this, the service starts working as soon as the package is installed.
> 
> Do people feel it is a good idea for packages to grab non-standard ports
> like this?

No, that seems like a bad idea.

How easily could you teach syslog-nagios-bridge to listen on a UNIX
domain socket, instead of or in addition to a TCP socket?  You could
then have it listen on /run/syslog-nagios-bridge by default, and have
rsyslog automatically forward messages there.

(Also, please consider providing a .socket file for systemd socket
activation.)

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140802162832.GA3791@thin

Re: packages using non-standard ports

[Henrique de Moraes Holschuh]

On Sat, 02 Aug 2014, Josh Triplett wrote:
> How easily could you teach syslog-nagios-bridge to listen on a UNIX
> domain socket, instead of or in addition to a TCP socket?  You could
> then have it listen on /run/syslog-nagios-bridge by default, and have
> rsyslog automatically forward messages there.

Unless this socket is *never* going to need any sort of access control, rule
zero for UNIX socket security applies: you must put it inside a directory.

I.e. unless this socket always has to be accessible by everyone, don't put
it directly in /run.  Use something like /run/syslog-nagios-bridge/socket,
and depend on the access permissions of /run/syslog-nagios-bridge/ to
control access to the socket.

That may well mean you need the directory just for the socket.  If you have
extra files that need different access restrictions, they'll have to go in a
separate directory.

> (Also, please consider providing a .socket file for systemd socket
> activation.)

And when you do that, beware that you will most likely have to take special
steps to work around bug #736258.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140802171736.ga12...@khazad-dum.debian.net

Re: Bug#756521: ITP: kadeploy -- Scalable, efficient and reliable cluster provisioning solution

[Luca Capello]

Hi there!

On Sat, 02 Aug 2014 14:35:33 +0100, Simon McVittie wrote:
> On 02/08/14 08:03, Charles Plessy wrote:
> > A straightforward way is exemplified by the case of SSH, where the server 
> > keys
> > are regenerated if they are absent.  It then only takes to delete the keys 
> > when
> > preparing images to avoid the problem of duplicated IDs or privacy leaks.
> 
> D-Bus (/var/lib/dbus/machine-id) also regenerates its machine ID during
> boot if required, although systemd (/etc/machine-id)

Thank you, I was not aware of the two aboves (even if only the first one
matters in a default wheezy).

BTW, /me wonders why two different files...

> Perhaps it would be good to define a "reset-machine-state" dpkg trigger
> or something; then tools like live-build could trigger it, and dbus
> could take responsibility for deleting /var/lib/dbus/machine-id when it
> is triggered? live-build etc. would have to keep their current hooks for
> now.

Is there a list of such files somewhere?  The current configure-host.sh
we use ATM after Clonezilla via debconf-set-selections (be aware of [1])
and dpkg-reconfigure deals with the following:

[AFAIK not managed by any debconf setting]
- /etc/hostname
- /etc/hosts

[debconf:
postfix postfix/mailname string HOSTNAME.DOMAIN
postfix postfix/destinations string HOSTNAME.DOMAIN, localhost.DOMAIN, 
localhost]
- /etc/mailname
- /etc/postfix/main.cf

[AFAIK not managed by any debconf setting]
- /etc/ssh/ssh_host_*_key
- /etc/ssh/ssh_host_*_key.pub

[debconf:
ssl-cert make-ssl-cert/hostname string HOSTNAME]
- /etc/ssl/certs/ssl-cert-snakeoil.pem
- /etc/ssl/private/ssl-cert-snakeoil.key

Obviously, I have now added the D-Bus machine-id as well.

As Lucas wrote for Kadeploy, the above should be done by Clonezilla
itself, which is not ATM.  Another Clonezilla problem is that it deals
with installing GRUB in the destination disk, but not with setting the
debconf installation device (which is currently missing in our script as
well, simply assuming /dev/sda is not always true).

Thx, bye,
Gismo / Luca

[1] debconf preseeding is useless, as explained in:

  


signature.asc
Description: Digital signature

Re: Bug#756521: ITP: kadeploy -- Scalable, efficient and reliable cluster provisioning solution

[Jeroen Dekkers]

At Sat, 02 Aug 2014 14:35:33 +0100,
Simon McVittie wrote:
> 
> On 02/08/14 08:03, Charles Plessy wrote:
> > A straightforward way is exemplified by the case of SSH, where the server 
> > keys
> > are regenerated if they are absent.  It then only takes to delete the keys 
> > when
> > preparing images to avoid the problem of duplicated IDs or privacy leaks.
> 
> D-Bus (/var/lib/dbus/machine-id) also regenerates its machine ID during
> boot if required, although systemd (/etc/machine-id) is not always able
> to do so (because it's pid 1, and our initramfs does not fsck the root
> filesystem, systemd typically starts before the root filesystem is
> read/write, but it wants to be able to have a machine ID immediately).
> 
> As of jessie, each will copy the other's idea of the machine ID if it
> exists, or create a new one if not; in wheezy, systemd would copy the
> D-Bus machine ID, but D-Bus would create a new ID rather than copying
> the one from systemd.
> 
> Some component still needs to know that those specific files should be
> reset when preparing a generic image, and how to reset them - for
> systemd it is actually better to truncate /etc/machine-id than to delete
> it, because if it exists as an empty file, systemd can do tricks with
> bind-mounts to mount a transient machine-id over the top, copying the
> one from dbus if available.
> 
> Perhaps it would be good to define a "reset-machine-state" dpkg trigger
> or something; then tools like live-build could trigger it, and dbus
> could take responsibility for deleting /var/lib/dbus/machine-id when it
> is triggered? live-build etc. would have to keep their current hooks for
> now.

I really like the idea proposed by the systemd developers: it should
be possible to just remove /etc and/or /var and the system should boot
and populate /etc and /var with the necessary files:

http://0pointer.de/blog/projects/stateless.html


Kind regards,

Jeroen Dekkers


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/878un6mx6o.wl%jer...@dekkers.ch

Re: Bug#756521: ITP: kadeploy -- Scalable, efficient and reliable cluster provisioning solution

[Simon McVittie]

On 02/08/14 19:16, Luca Capello wrote:
> On Sat, 02 Aug 2014 14:35:33 +0100, Simon McVittie wrote:
>> D-Bus (/var/lib/dbus/machine-id) also regenerates its machine ID during
>> boot if required, although systemd (/etc/machine-id)
>
> BTW, /me wonders why two different files...

The idea came from D-Bus, whose developers wanted a way to say,
unambiguously, "this is the same machine", "this is a different
machine". The systemd developers considered that to be a sufficiently
useful concept that they wanted systems without D-Bus to be able to rely
on it.

systemd doesn't want to depend on the D-Bus location because it's
D-Bus-specific, isn't guaranteed to be available when pid 1 starts (it's
in /var), and there's no formal specification for where it is[1].

If everything goes well, whenever those two files both exist, they
should contain the same thing.[2]

> Is there a list of [files that need resetting] somewhere?

No, and in a set of packages as large as Debian, a centralized list (for
things beyond some vaguely-defined base OS that could reasonably include
systemd and dbus but probably not postfix) seems doomed to failure.
That's why I suggested a dpkg trigger that could distribute that
knowledge between the packages involved.

Having said that, the live-* suite of packages makes a good attempt at a
centralized list.

S

[1] The de facto standard is "what dbus does when configured with
--localstatedir=/var" because virtually all distros are FHS, but the
default in an unconfigured build from source is technically
/usr/local/var/..., because Autotools does not default to a FHS location.

[2] Existing installations that installed systemd first, and dbus (<<
1.8.2) later, might have them differ. Fortunately, this seems unlikely
to happen in Debian, since the sort of people who installed systemd on
wheezy systems probably already had dbus.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53dd7189.10...@debian.org

Bug#756884: ITP: ruby-spring -- Rails application preloader

[Antonio Terceiro]

Package: wnpp
Severity: wishlist
Owner: Antonio Terceiro 

* Package name: ruby-spring
  Version : 1.1.3
  Upstream Author : Jon Leighton
* URL : http://github.com/rails/spring
* License : MIT
  Programming Lang: Ruby
  Description : Rails application preloader

Spring is a Rails application preloader. It speeds up development by
keeping your application running in the background so you don't need to
boot it every time you run a test, rake task or migration.

This is a dependency for the Rails 4.x stack and will be maintained
inside the Debian Ruby team.

-- 
Antonio Terceiro 


signature.asc
Description: Digital signature

Re: packages using non-standard ports

[Daniel Pocock]

On 02/08/14 19:17, Henrique de Moraes Holschuh wrote:
> On Sat, 02 Aug 2014, Josh Triplett wrote:
>> How easily could you teach syslog-nagios-bridge to listen on a UNIX
>> domain socket, instead of or in addition to a TCP socket?  You could
>> then have it listen on /run/syslog-nagios-bridge by default, and have
>> rsyslog automatically forward messages there.
> 
> Unless this socket is *never* going to need any sort of access control, rule
> zero for UNIX socket security applies: you must put it inside a directory.
> 
> I.e. unless this socket always has to be accessible by everyone, don't put
> it directly in /run.  Use something like /run/syslog-nagios-bridge/socket,
> and depend on the access permissions of /run/syslog-nagios-bridge/ to
> control access to the socket.
> 
> That may well mean you need the directory just for the socket.  If you have
> extra files that need different access restrictions, they'll have to go in a
> separate directory.
> 

Using a UNIX socket involves:

- patching python-netsyslog to create the socket instead of binding to a
TCP port (this is not hard)

- using rsyslog's omuxsock module

http://www.rsyslog.com/doc/omuxsock.html

Looking at that, it appears less flexible than TCP as the socket name is
defined globally, so if somebody else already writes to some socket,
maybe they can't have multiple output sockets?  Or maybe that is just a
shortcoming in the documentation/example though?

It would also be necessary to check how rsyslog behaves when the socket
is not there (e.g. if rsyslog starts before syslog-nagios-bridge or if
syslog-nagios-bridge is restarted).  Using TCP, rsyslog caches the
messages for peers that are temporarily offline.

However, I agree the UNIX socket is more flexible than hard-coding some
port number and it is also easier to align with current security
practices for log data (e.g. the socket would only be accessible to
root, just like /var/log/*)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53ddd947.6020...@pocock.pro