Re: Make systemd journal persistent | remove rsyslog (by default)

[Jamie Strandboge]

On Wed, 2017-01-11 at 08:29 +0100, Martin Pitt wrote:
> Jamie Strandboge [2017-01-10 16:27 -0600]:
> > 
> > Remote logging. Rsyslog is far superior in this regard. Granted, remote
> > logging
> > is not enabled by default but it is a requirement in many environments.
> The systemd-journal-remote package does provide the necessary tools and is
> reasonably flexible (push or pull, builtin https or using arbitrary ports
> which
> you e. g.  could forward through ssh). It might not be as flexible as rsyslog,
> but as one needs to set up remote logging manually anyway, you always have the
> possibility of picking rsyslog, journal, or even something else.
> 
Yes, but the 'logged to' system needs to be running systemd[1]. rsyslog speaks
the standard syslog protocol on 514/udp, but systemd-journal does not.

[1]https://www.freedesktop.org/software/systemd/man/systemd-journal-remote.html

-- 
Jamie Strandboge | http://www.canonical.com



signature.asc
Description: This is a digitally signed message part
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Make systemd journal persistent | remove rsyslog (by default)

[Martin Pitt]

Jamie Strandboge [2017-01-10 16:27 -0600]:
> Remote logging. Rsyslog is far superior in this regard. Granted, remote 
> logging
> is not enabled by default but it is a requirement in many environments.

The systemd-journal-remote package does provide the necessary tools and is
reasonably flexible (push or pull, builtin https or using arbitrary ports which
you e. g.  could forward through ssh). It might not be as flexible as rsyslog,
but as one needs to set up remote logging manually anyway, you always have the
possibility of picking rsyslog, journal, or even something else.

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


signature.asc
Description: PGP signature
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Ubuntu LTS 16.04, libmpich-dev:i386, wrong dependencies in package

[Dandy Eschricht]

Dear Maintainers,

i am trying to install libmpich-dev:i386 with the following outcome:
root@ubuntu:~/MPICH_1604# apt-get install libmpich-dev:i386
...
The following packages have unmet dependencies:
 libmpich-dev:i386 : Depends: gfortran:i386 but it is not going to be installed
 Depends: g++:i386 but it is not going to be installed
E: Unable to correct problems, you have held broken packages.


Please note, that gfortran:i386 and g++:i386 are neither required to use the 
package, nor do they appear in the dependencies list.
Details on the package libmpich-dev, i put at the end of this mail.

I have the following packages installed (which allows me to build 32- and 
64-bit applications using gcc, g++ and gfortran):
root@ubuntu:~/MPICH_1604# dpkg --get-selections | grep gfortran
gfortraninstall
gfortran-5  install
gfortran-5-doc  install
gfortran-5-multilib install
gfortran-docinstall
lib32gfortran-5-dev install
lib32gfortran3  install
libgfortran-5-dev:amd64 install
libgfortran3:amd64  install
libx32gfortran-5-devinstall
libx32gfortran3 install

root@ubuntu:~/MPICH_1604# dpkg --get-selections | grep g++
g++ install
g++-5   install

Please mind that after a force install via:
root@ubuntu:~/MPICH_1604# apt-get download libmpich-dev:i386
and
root@ubuntu:~/MPICH_1604# dpkg --force-depends -i 
libmpich-dev_3.2-6build1_i386.deb
all required files to compile and link are available.
mpich-packages installed now:
root@ubuntu:~/MPICH_1604# dpkg --get-selections | grep mpich
libmpich-dev:i386   install
libmpich12:i386 install
mpich:i386  install
mpich-doc   install

and building mpich-applications works fine using either:
mpicc.mpich -o ../bin/hello hello.c -m32
or
gcc -o ../bin/hello hello.c -m32 -I/usr/include/mpich/ 
-L/usr/lib/i386-linux-gnu -lmpich
or
mpif90.mpich -cpp -o ../bin/hello hello.f90 -m32

I do not know whether the problem is on the apt side.
If apt translates the dependency gfortran to gfortran:i386 because the package 
is :i386 then the bug is in apt.
Please let me know if should file a bug for apt.

Best Regards,
Dandy


root@ubuntu:~/MPICH_1604# apt-cache show libmpich-dev:i386
Package: libmpich-dev
Priority: extra
Section: universe/libdevel
Installed-Size: 6891
Maintainer: Ubuntu Developers 
Original-Maintainer: Debian Science Maintainers 

Architecture: i386
Source: mpich
Version: 3.2-6build1
Replaces: libmpich1.0-dev, libmpich2-dev, libmpl-dev, libopa-dev
Depends: gfortran, g++, libcr-dev, libmpich12 (= 3.2-6build1), libc6 (>= 2.7), 
libcr0 (>= 0.8.2)
Recommends: mpich (= 3.2-6build1)
Breaks: libmpich1.0-dev, libmpich2-dev, libmpl-dev, libopa-dev
Filename: pool/universe/m/mpich/libmpich-dev_3.2-6build1_i386.deb
Size: 1182728
MD5sum: f38849c1b456fc3633d499a1e1a77038
SHA1: f30dc911c5d160a313fb304f4249773cc8c65e8f
SHA256: f441e1e1c1da783a877733fef6f62dc3189bc5a810b2449813442d9225faffa0
Description-en: Development files for MPICH
 MPICH is a high-performance and widely portable implementation of the
 Message Passing Interface (MPI) standard (both MPI-1 and MPI-2). It
 efficiently supports different computation and communication platforms
 including commodity clusters, SMPs, massively parallel systems, and
 high-speed networks.
 .
 This package includes the MPICH headers and static libraries, as well
 as the compiler wrappers needed to build MPICH programs.
Description-md5: 3c6557ee2e0f267fcc0f7b3491d99d3c
Homepage: http://www.mpich.org/
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Origin: Ubuntu

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Make systemd journal persistent | remove rsyslog (by default)

[Fiedler Roman]

> From: ubuntu-devel-boun...@lists.ubuntu.com [mailto:ubuntu-devel-
>
> Jamie Strandboge [2017-01-10 16:27 -0600]:
> > Remote logging. Rsyslog is far superior in this regard. Granted,
> remote logging
> > is not enabled by default but it is a requirement in many
> environments.
>
> The systemd-journal-remote package does provide the necessary tools and is
> reasonably flexible (push or pull, builtin https or using arbitrary ports 
> which
> you e. g.  could forward through ssh). It might not be as flexible as
> rsyslog, but as one needs to set up remote logging manually anyway, you 
> always
> have the possibility of picking rsyslog, journal, or even something else.

I have done a POC with systemd-journal-remote yet, but that sounds quite good.
In our production environment following features should be supported also by
Rsyslog replacements to support current usecases and ease gradual rollout:

1) rsyslog RELP mode (reliable remote transport) - reduces probability for 
lost messages during network maintenance, e.g. statefull firewall restarts 
without conntrack failover.

2) Remote log data caching on network downtimes - data should be transmitted 
when network up again

3) Cascading operation: branch offices or guest perform remote logging to a 
nearby concentrator, only the concentrator has to be granted off-site access 
in firewall

4) TLS support with own CA - each new machine will get a new certificate from 
deployment system, central logging should accept traffic from all those 
machines with valid certificate automatically (eases automatic rollout)

5) rsyslog/system hybrids: in early phase there will be e.g. some old rsyslog 
based LXC containers forwarding logs to systemd-only hosts and perhaps also 
vice versa.

6) Streams > 10GB logs/day should not cause any troubles, log data losses.

7) Integration with SIEMs or logmanagement solutions, e.g. graylog.

Perhaps not all those features are possible/sensible to have 
systemd-journal-remote. In that case another requirement could arise:

8) Allow local rsyslog/systemd-journal-remote combination: systemd forwards 
the logs to a local rsyslog (which might also process other remote data from 
requirement 3), and all the really remote forwarding will happen using 
old-style rsyslog. Of course this would require maintenance of automation 
scripts for setup/automatic configuration of both rsyslog/systemd in various 
flavours (host/LXC-guest, Trusty/Xenial/CentOS)


I put it on my list, that I have to do a ~3 machine POC with 
systemd-journal-remote only setup to check all those requirements. As rsyslog 
is not completely trouble-free, this might help cut down costs in the long 
run.

Roman


smime.p7s
Description: S/MIME cryptographic signature
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: bash completion issue in 16.04

[Jarno Suni]

Can you give the argument as separate word without '=' ? Or remove the 
character from environment variable COMP_WORDBREAKS
That does not remove the bug, though.

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss