Am 14.03.2017 um 21:43 schrieb Nico Kadel-Garcia:> On Tue, Mar 14, 2017 at 4:20 PM, Thomas G?ttler > <guettliml at thomas-guettler.de> wrote: >> >> >> >> Am 14.03.2017 um 15:10 schrieb Nico Kadel-Garcia: >>> Look into the "autossh" program, which is very good to manage and >>> maintain such tunnels. >>> >> >> Hi Nico and other ssh users, >> >> Systemd restarts the ssh if it terminates. AFAIK this is all that is needed. >> >> But maybe I am missing something. Is there a feature of autossh that I don't >> get with systemd? > > Better logging, especially error reporting,I am happy with the messages which gets passed from the ssh process to systemd. Could you please provide an example, since I fail to see what autossh does better.> and much more modular > configuration for multiple parallel autossh daemons without having to > hand edit and customize systemd init scripts.We use configuration management to create and update systemd unit configuration files. I don't see how autossh can help here. Do you have an example?> I've had some success > with using chef to manage it, along with deploying SSH configurations > to avoid the "known_hosts" mismatched hostkey issues as target hosts > change IP address, and to get management of the relevant public and > private SSH keys for the port forwarding.I can't follow. My brain is still focused on the question: Why autossh? Regards, Thomas -- Thomas Guettler http://www.thomas-guettler.de/
On Wed, Mar 15, 2017 at 5:13 AM, Thomas G?ttler <guettliml at thomas-guettler.de> wrote:>> and much more modular >> configuration for multiple parallel autossh daemons without having to >> hand edit and customize systemd init scripts. > > > We use configuration management to create and update systemd unit > configuration files. > I don't see how autossh can help here. Do you have an example?I found the logging in /var/log/autossh{-instancename}, and the management of multiple autossh configurations, to be much more manageable and reportable through configuraiton managed /etc/sysconfig/autossh{-intancename} files than via the confusing and Linux-kernel-only logging of systemd. I found authorship and maintenance of those files, *outside* of the SELinux and default systemd configurations, to be far more flexible and reliable for my uses. And even debugging the "ssh client is getting restarted too fast and port isn't released" was painful when I encountered it in similar environments.> I can't follow. My brain is still focused on the question: Why autossh?You've taken the time to say that you have systemd configured through a separate management tool. For me, this is one of many instances for which I find sytemd's centralization and merging of all logging into a single log repository awkward and unnecessary. So please allow me to invert the question. What logging benefit or maintenance benefit are you gaining from inserting autossh instance specific configurations into systemd init files, and losing the segregation of autossh logs into individually parseable and reviewable log files?
Am 16.03.2017 um 00:48 schrieb Nico Kadel-Garcia:> On Wed, Mar 15, 2017 at 5:13 AM, Thomas G?ttler > <guettliml at thomas-guettler.de> wrote: > >>> and much more modular >>> configuration for multiple parallel autossh daemons without having to >>> hand edit and customize systemd init scripts. >> >> >> We use configuration management to create and update systemd unit >> configuration files. >> I don't see how autossh can help here. Do you have an example? > > I found the logging in /var/log/autossh{-instancename}, and the > management of multiple autossh configurations, to be much more > manageable and reportable through configuraiton managed > /etc/sysconfig/autossh{-intancename} files than via the confusing and > Linux-kernel-only logging of systemd. I found authorship and > maintenance of those files, *outside* of the SELinux and default > systemd configurations, to be far more flexible and reliable for my > uses. And even debugging the "ssh client is getting restarted too fast > and port isn't released" was painful when I encountered it in similar > environments. > >> I can't follow. My brain is still focused on the question: Why autossh? > > You've taken the time to say that you have systemd configured through > a separate management tool. For me, this is one of many instances for > which I find sytemd's centralization and merging of all logging into a > single log repository awkward and unnecessary. > > So please allow me to invert the question. What logging benefit or > maintenance benefit are you gaining from inserting autossh instance > specific configurations into systemd init files, and losing the > segregation of autossh logs into individually parseable and reviewable > log files?Of course, I like questions. I like simple systems. If I can avoid a daemon, then I do it. Systemd is the process-Supervisor on my operating system. If there are no good reasons for an other process-Supervisor, then I use systemd. Logging via systemd is no problem for me. One reason to use autossh is the ugly ExecStartPre which I use to kill and old tunnel. Regards, Thomas G?ttler -- Thomas Guettler http://www.thomas-guettler.de/