Tag Info

Hot answers tagged

22

You want to remove the passphrase from a key file. Run this: openssl rsa -in key.pem -out newkey.pem


13

I've been guilty of removing the passphrase from my own key files in the past, because it's the simplest solution, but security-wise, it's not the best idea. An alternative is to feed the passphrase to Apache. You can do this with the SSLPassPhraseDialog option in your httpd.conf (or another file that it includes). If you only have one SSL site on your ...


13

There are a couple ways. If you just want to do this temporarily, you can remove the execute bit from the file: $ chmod -x /etc/init.d/varnish Then re-add it when appropriate: $ chmod +x /etc/init.d/varnish The "official" way in Ubuntu (as well as in Debian and other Debian derivatives), though, is to use the update-rc.d command: $ update-rc.d varnish ...


9

I don't see a problem with it, if you know, for sure, that the Python interpreter will be available when the init.d script is being run. This, to me, indicates that you're looking at something being done relatively late in a multi-user (or "graphic console") run-level. However... This means that a specific version of the Python interpreter MAY be vital for ...


9

The best way to go for it are the daemontools. They allow you to monitor and respawn processes. See the documentation on their website: http://cr.yp.to/daemontools.html


9

supervise is a lightweight, efficient alternative. Under debian it is packaged in daemontools. You can also read this related question, which lists some supervise criticisms, and mentions restartd as another possibility. Finally, if you want something incredibly easy to setup, I've had great success with monit. It is also packaged in Debian.


9

First of all, init scripts are supposed to be run sudo /etc/init.d/name when you are not logged in as root( when logged-in user is sudo enabled) Secondly, when you run sudo /etc/init.d/nginx start ==> it fires the master nginx process as root and worker processes as the user you specified in your nginx.conf user directive(eg. www-data) Can you confirm ...


9

Yes. There are issues of availability, speed, reliability, maintainability, etc, but init scripts can be written in whatever you want. As is implied in your question, the /usr filesystem must be mounted before you can use the interpreters residing on it. There are Perl modules for just this task. One example is Daemon::Control, there are many more for ...


8

I'd say #2, but very close to #1 -- "Bad. Bad. Bad. Never do this." The standard, such as it is, for Linux init scripts is in the LSB, and while it never comes out and says "these are bourne shell scripts", several assumptions are made. One, that lines beginning with # are comments, happens to work out fine. More problematic is the requirement that the init ...


8

So set it up to start at boot: chkconfig php-fpm on


7

You can just su. You won't need the password because the script will initally be running as root. There's also the runuser command. If you use /etc/init.d/functions you can use the daemon function which has an option for specifying the user to run as. I'd personally sway towards the latter all other things being equal.


7

xbindkeys needs a running X server to work which isn't available at that stage of starting your system. You should add xbindkeys to your .xinitrc (see man page xinit(1)) or .Xsession (see man page Xsession(5)) instead.


7

Putting a file readable only by root somewhere into /etc is a technique I've come across a few times at least in Debian (dbconfig-common does that, for example). Sourcing a file with plain passwords belonging to root sounds like quite a good idea to me, given the fact that init runs as root and there's already a lot of sensitive files in /etc anyway ...


7

I agree that your solution seems a bit complex, so I'll go with "give me some idea how this could be implemented in an entirely different way" :-) The standard solution for this is to use a configuration management system, such as puppet, and allow users to add their stuff to the puppet config for the server. Puppet will then push out the start script and ...


6

If you run the script at boot time, when no one is logged in, how could it modify anything in the user's session? :-) You should run it from your .bash_profile startup script (or from /etc/profile, to run it for every user in the system).


6

Correct stop: start-stop-daemon --stop --oknodo --pidfile $PIDFILE


6

Use chkconfig: chkconfig --level 345 mysqld on


6

Passing 1 on the kernel line in the bootloader should start it in single user mode, which should not start the initscript unless it is severely broken. If booting into single mode does not work then you will need to get the install disc and boot into rescue mode using it.


6

As Ignacio suggested, the simplest solution is to boot into single user mode. To do this press any key on the countdown splash screen before it boots into the kernel. From here highlight the proper kernel and press e. Press e again to edit the cmdline and at the end at either S, s, single, or 1. Press return and then b to boot. This won't run your init ...


6

Depending on your Linux distro and release, ultimately sysvinit scripts (those scripts in /etc/init.d/) are generally run from the symlinks which exist in /etc/rc[0-6S].d, by /etc/init.d/rc. Under Ubuntu, you're either using old-style sysvinit, or more recently, upstart. Under the upstart management directory (/etc/events.d/) you'll find a legacy mode that ...


6

See the man page for update-rc.d. To stop a service from running at boot: update-rc.d -f servicename remove Or: update-rc.d servicename stop 20 2 3 4 5 . If you have Debian squeeze or later, or Ubuntu 12.10 or later: update-rc.d servicename disable To allow a service to run at boot: update-rc.d servicename defaults If you have Debian squeeze ...


6

iniscripts can do whatever they want. Of course it makes sense not to introduce new dependencies, just for the initscripts. grep however is fine on pretty much any system that's posix/susv3 compatible (linux, bsd, solaris, other derivatives). For more utilities that should always be there, see ...


5

These days init is actually being replaced by upstart in Ubuntu server. So what you probably want to do if you are writing these scripts is to try to write upstart ones instead of init. Here is a Getting Started Guide for upstart in Ubuntu.


5

If avahi-daemon is in /etc/init.d and you want to have it started at each boot, just add it to the startup scripts with: sudo update-rc.d avahi-daemon defaults But i'm surprised that avahi-daemon is not still linked in the required runlevels as it was probably added by the system. To have your disk mounted at boot, add a line in your fstab like suggested ...


5

You can start the service manually by using sudo start avahi-daemon and not using sudo avahi-daemon start If you want it so the service starts at boot. You need to have a look at adding a symlink to /etc/rc2.d/ to point at /etc/init.d/avahi-daemon. It is probably easier to read up on the programs sysv-rc-conf or update-rc.d For mounting a disk you ...


5

Check out /etc/init.d/skeleton for an example. This should be present on an Ubuntu host.


5

You could make a function to echo the message to both the screen and to syslog, something like this: LOGGER="/usr/bin/logger -t $myScript" # check the location of logger for your system myEcho () { echo "$1" $LOGGER "$1" } You could also put that into a separate file and include it into your scripts with #!/bin/bash myScript=$(basename $0) [ ...


5

I don't know what's causing this problem in particular, however in general if you're having troubles with a script (such as an init script) it's worth running it under a shell with the -x option (eg /bin/bash -x /etc/init.d/php5-fpm start), which will print out a full trace of the script's execution, which will almost certainly make it obvious what's going ...


5

Files in /etc/profile.d/ are run when a user logs in (unless you've modified /etc/profile to not do this) and are generally used to set environment variables.


5

I would say don't look at the current distro to determine which init system to use to manage daemons: It's a little nebulous to determine a distro (as described in Dennis's answer) the init system in use changes between versions of a distro (as Michael Hampton noted, the big name distros are all gravitating toward systemd; Ubuntu is currently the one ...



Only top voted, non community-wiki answers of a minimum length are eligible