0

I'm trying to execute a test in different Linux server distros (Fedora, Ubuntu, Centos, etc).

I know that there is an init system that can allow programs execution after boot (without login). The problem is that I don't want to have a special case for every different init system between distros. Is there a way to allow root auto login after boot?

By doing this I can have the same shell script for any distro. Or is there a way to workaround this issue?

gbriones.gdl
  • 123
  • 7

4 Answers4

2

you added a comment: "I have a program that needs to be tested physically on different Linux distros to report performance"

in this case, you might want to consider using docker, that way you dont really need a full os or anything...but if your program for some reason needs to be run on a physical instance, you might want check out some job execution environment like jenkins

1

I'm confused about what you want, however if you want to run something as root after boot on Linux, stick it in here on most distros:

/etc/rc.local

Or sometimes

/etc/rc.d/rc.local
Ryan Babchishin
  • 6,160
  • 2
  • 16
  • 36
  • Does this also work in Ubuntu? – gbriones.gdl Oct 09 '15 at 19:06
  • Yes, I just verified that /etc/rc.local was correct on my Ubuntu and Debian systems. – Ryan Babchishin Oct 09 '15 at 19:07
  • I recall that SUSE keeps it somewhere weird. I had difficulty with that a long time ago. I think Redhat/CentOS/Fedora are like Ubuntu. – Ryan Babchishin Oct 09 '15 at 19:10
  • Is rc.local executed at the end of last runlevel? my program requires some services to start up previously. – gbriones.gdl Oct 09 '15 at 19:56
  • @gbriones.gdl rc.local is usually executed at the very end of the boot process, just before spawning the login getty on the boot console. You would however need to verify that on each specific system to be 100% certain. – user Oct 09 '15 at 20:14
0

If it is a command line programming a better approach would be to execute it through SSH. Furthermore you can use SSH keys to login without passwords.

0

I know that there is an init system that can allow programs execution after boot (without login).

Unfortunately these days there is not one init system there is a half dozen popular init systems. For example sysv init, systemd, upstart, etc.

Anyway, if you really want a system to provide you with a console that has root access, you would probably want to update your init system.

I do this for a serial port on a couple of my systems. I have have two very different configurations and I am only using Debian with two different releases. I can't imagine that you will be able to come up with a single method that will apply across all distros. There is just no consistency for how things get started. Systemd should be pretty similar across distros, but it isn't broadly accepted yet.

Debian with sysv init (wheezy) drop to root on serial port

# /etc/inittab
...
# serial port getty spawns sulogin, which drops to a root shell
# on debian if root has a disabled password
T0:23:respawn:/sbin/getty -n -l /sbin/sulogin -L ttyS0 57600 vt102
...

Debian with systemd (jessie) drop to root on serial port

#/etc/systemd/system/getty.target.wants/serial-getty@ttyS1.service
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

[Unit]
Description=Serial Getty on %I
Documentation=man:agetty(8) man:systemd-getty-generator(8)
Documentation=http://0pointer.de/blog/projects/serial-console.html
BindsTo=dev-%i.device
After=dev-%i.device systemd-user-sessions.service plymouth-quit-wait.service
After=rc-local.service

# If additional gettys are spawned during boot then we should make
# sure that this is synchronized before getty.target, even though
# getty.target didn't actually pull it in.
Before=getty.target
IgnoreOnIsolate=yes

[Service]
ExecStart=-/sbin/agetty -n -l /sbin/sulogin --keep-baud 115200,38400,9600 %I $TERM
Type=idle
Restart=always
UtmpIdentifier=%I
TTYPath=/dev/%I
TTYReset=yes
TTYVHangup=yes
KillMode=process
IgnoreSIGPIPE=no
SendSIGHUP=yes

[Install]
WantedBy=getty.target

Your best bet might be to give up on the idea of logging in as root, and instead use a configuration management tool like puppet or that can abstract away some various distro-release differences for you. Have that tool trigger your test runs.

Zoredache
  • 128,755
  • 40
  • 271
  • 413
  • My fedora says that /etc/inittab is no longer used. Does this mean that it won't work or that it's just deprecated – gbriones.gdl Oct 09 '15 at 19:23
  • I am pretty Centos/Fedora has gone to the SystemD way of doing things for their newest releases. I think Ubuntu is mostly still upstart, Debian tries to have it both ways. – Zoredache Oct 09 '15 at 19:25
  • Actually, Debian doesn't really try to have it both ways; up to and including Wheezy, sysvinit is the default (with systemd offered as an alternative on newer versions); from Jessie onwards, systemd is the default, with sysvinit as the "unsupported but should mostly work, but don't blame us if it breaks" alternative. – user Oct 09 '15 at 20:13