### BEGIN INIT INFO
# Provides:          defaultdaemon
# Required-Start:    $remote_fs $syslog
# Required-Stop:     $remote_fs $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Start daemon at boot time
# Description:       Enable service provided by daemon.
### END INIT INFO

После этого

update-rc.d имя defaults

Для удаления скрипта из автозагрузки

update-rc.d -f имя remove

I had very bad HDD crashes recently and i think the problem is the extreme use of my system which is on almost for 22 hrs a day on holidays and 14hrs on weekdays.

So i decided to make a tool to notify me when it is 1hr of use and give me options to shutdown and continue using.
This was the first thing i did after installing an OS on the replaced HDD this time. My of the insipriation for trying it out is my senior at college srijith.

He also has a similar tool but more better.
So here goes the stuff.

my username is cyriac
and i belong to a group script on my system.

Basic things to do prior to working my script.

edit the sudoers file.
log in as root
visudo
add the line
%script ALL=NOPASSWD: ALL

note that i belong to the group script
now create a folders in the home directory with names /logs and /logs/timeupdude

mkdir ~/logs/timeupdude -p

make a textfile with name timeupdude
and paste the code below.

work=TRUE
echo "60" > /home/cyriac/logs/timeupdude/testf
while [ $work = TRUE ]
do
tt=`cat /home/cyriac/logs/timeupdude/testf`
if [ $tt -eq 0 ]
then
ans=`zenity - -title "TIME UP DUDE" - -text "YOUR UPTIME IS OVER AN HOUR NOW " - -list - -radiolist - -column "SELECTION" - -column "ACTION" False SHUTDOWN True CONTINUE_WORKING`
if [ $ans = CONTINUE ]
then
echo "60" > /home/cyriac/logs/timeupdude/testf
else
sudo shutdown -ah now
fi
else
sleep 60
tt=`expr $tt - 1`
echo $tt> /home/cyriac/logs/timeupdude/testf
fi
done

Save the file and make it excec by

chmod +x timeupdude

copy the file to /etc/init.d
and add it to the boot up

update-rc.d timeupdude defaults

Now restart the computer and the timeupdude is on the run..
The tool first shows the screen below when it is 1hr.

If SHUTDOWN is pressed the system shuts down else if CONTINUE_WORKING is pressed you can continue working until this window again pops up in 30mins

You can also edit the time by scannin my script.
And this script works with Gnome machines only.

Please note that the options in the zenity needs to be - - ie minusminus. not --
Will come up with a new version with the ideas my `guru`;) suggested.. :P

New code available

Please leave comments so that i can find mistakes i made and improve.. :)

[sourcecode language="php"]
sudo apt-get install php5-imap
[/sourcecode]

Depois da instalação é necessário reiniciar o Apache:

[sourcecode language="php"]
sudo /etc/init.d/apache2 restart
[/sourcecode]

I have a VPS that hosts my Django application via FastCGI behind nginx on Ubuntu 7.10. Nginx comes with an init.d script which starts it at boot time (for me on Ubuntu it runs as /etc/rc5.d/S20nginx -> /etc/init.d/nginx) but I was having to turn the Django app on (via FastCGI) every time the server was rebooted. Since the only reason nginx runs was for my Django app, I wanted the app to start up just like nginx does so that on a reboot, server crash, etc I don't need to ssh in and restart the app. To do this, I started with the posting on the Django wiki (http://code.djangoproject.com/wiki/InitdScriptForLinux), and then tweaked it for my own purposes, mainly: one single Django app.

The idea here is that I'd simply run `/etc/init.d/my_django_app start` and be done with it while the server itself would do this automatically when it boots up. Here is what I did to let me do this.

1. Tweaked the init.d script, you can find it here:
   http://static.geewax.org/my_django_app
2. Copied that script into `/etc/init.d/my_django_app`
3. Ran `update-rc.d my_django_app defaults`
4. Rebooted the machine to test it out

Note that the update-rc.d (I'm told) is only for Ubuntu (or Debian-like) systems.

Now, if I wanted to run more than one app, I can copy the script to a different name and follow the procedure again which lets me do fine-grained application enabling/disabling of Django services should the need arise.

The /etc/inittab is a typical inittab file, but as installed doesn't contain any comments to explain its entries. There is, however, a decent description in the man page inittab(4).

To configure the startup, all the parameters can be found in files in the /etc/rc.config.d directory; this directory is read by /etc/rc.config. Some startup programs read their configuration files directly, and some use /etc/rc.config to read all files.

The startup initialization files are found in /sbin/init.d (which is perhaps unlike most). /sbin/rc is run to begin the startup scripts. As mentioned, these files are in /sbin/init.d, but they are run from /sbin/rc[0-9].d directories. These directories will contain links to files in /sbin/init.d. Across all of these directories, there only needs to be two files: one to start the daemon in the right runlevel, and one in the next lower runlevel to stop it.

For example, consider the cron daemon:

# ls -1Fd /sbin/rc*.d/*cron
/sbin/rc1.d/K270cron@
/sbin/rc2.d/S730cron@

(First a note about the options to ls: -1 means list only filenames, -F adds the filetype designator at the end of the filename, and -d lists directories and not their contents.)

When HP-UX starts up (or changes to a higher runlevel) it runs start scripts (the S### scripts) as it goes from one level to the next until it reaches the desired level. When going to a lower runlevel, the system runs the kill scripts (the K### scripts) in order to stop processes.

The two listed files above (K270cron and S730cron) follow the [SK][0-9][0-9][0-9]script convention, and the file these link to is accordingly /sbin/init.d/cron. The numbers help to define the order that the scripts are run in; scripts are run in alphabetic order as defined by the (system) shell.

The startup scripts themselves are somewhat typical: a first parameter of start will start the service; a first parameter of stop will stop the service. Two other expected parameters are start_msg and stop_msg; these are used during the startup to provide a decently readable account of what is going on.

The scripts should return one of the following values as its exit value:

• 0. Success!
• 1. Failure.
• 2. Noop - translates to N/A (not applicable) during startup; script did nothing.
• 3. Script will cause a reboot (and will display /etc/rc.bootmsg if it contains anything).
• 4 and up. Treated same as 1.

All of the output from the startup and shutdown scripts is stored in /etc/rc.log (and the previous rc.log is moved to rc.log.old). Only the last two startup logs are kept. Here is a snippet of an rc.log:

Old /etc/rc.log moved to /etc/rc.log.old
 
**************************************************
HP-UX Start-up in progress
Thu Dec 13 13:56:28 CST 2007
**************************************************
 
Configure system crash dumps
Output from "/sbin/rc1.d/S080crashconf start":
----------------------------
crashconf: concurrent mode not supported on this platform
EXIT CODE: 0
 
Removing old vxvm files
Output from "/sbin/rc1.d/S090sw_clean_vxvm start":
----------------------------
 
VxVM INFO V-5-2-3360 VxVM device node check
Output from "/sbin/rc1.d/S091vxvm-nodes-check start":
----------------------------
 
VxVM INFO V-5-2-3362 VxVM general startup
Output from "/sbin/rc1.d/S092vxvm-startup start":
----------------------------

More information can be had on the rc(1m) and rc.config(4) man pages.

In linux tutti gli script che vengono eseguiti all'avvio del sistema e non della singola sessione, si trovano in una speciale directory, per niente nascosta, ma modificabile solamente come root :

/etc/init.d/

Chi non ha qualche scaramuccia col pinguino scagli il primo script! Beh personalmente ho avuto problemi relativi al caricamento automatico di alcuni moduli all'avvio del sistema. I miei problemi erano relativi al fatto che non riuscivo a gestire i governor per lo scaling in automatico all'accensione, ma dovevo invece andare a caricare manualmente dei moduli, e non riuscivo a caricare i moduli driver per la webcam integrata nel pannello dell' LCD del mio Asus. Mi sono quindi fatto uno script chiamato servizi personali, e dopo averne modificato i privilegi, usando i privilegi di root, l'ho copiato proprio nella cartella sopra citata. Supponiamo che lo script si trovi nella cartella Scrivania, e che si chiami servizi_personali, ecco cosa ho fatto per cambiarne i privilegi e copiarlo:

raffaele@raffaele-laptop:~$ cd Scrivania
raffaele@raffaele-laptop:~$ sudo chmod 755 servizi_personali
raffaele@raffaele-laptop:~$ sudo cp servizi_personali /etc/init.d/servizi_personali

Bisogna poi settare lo script per essere eseguito all'avvio. Io personalmente l'ho fatto con il programma bum, che deve essere eseguito come root, molto intuitivo nel suo uso. Una schermata di come tale programma si presenta è mostrata nell'immagine riportata. Spero di essere risultato abbastanza chiaro.

]]> http://switchbuntu.wordpress.com/2007/10/18/hamachi-vpn-on-ubuntu/ Thu, 18 Oct 2007 22:53:35 +0000 Tommy http://switchbuntu.it.wordpress.com/2007/10/18/hamachi-vpn-on-ubuntu/ I finally have gHamachi and the underlying Hamachi working on my Ubuntu setup.  It mostly just worked, but was a pain in the arse at some points.  Anyway, I realized that I didn't know how to make things startup automatically in Ubuntu.  In Windows, of course, you drop a shortcut to whatever you want running in the "Startup" folder under Start Menu->Programs->Startup.  What's the equivalent in Ubuntu (or Linux generally) for that matter?

According to the CompuTech Group, it looks like dropping something in /etc/init.d is the equivalent of the Windows Startup folder.  Anyway, I hope I can get gHamachi and Pidgin to autostart upon login.

The CompuTech Group » Blog Archive » HOWTO: Setup Hamachi VPN on Ubuntu

Here's to tinkering...

Para acessar diretamente este artigo no novo endereço clique no link abaixo:

http://www.jornaldojerimum.com.br/2007/10/04/como-configurar-um-firewall-iptables-no-ubuntu-usando-um-script-de-init/

O conteúdo deste artigo já foi migrado para o link citado, favor acessar no novo endereço!

Atenciosamente,

Allan Garcia