Server Stop, Start, Restart (Apache, SSH, MySql, Qmail)

Apache:

Q. I’m using CentOS / RHEL / Fedora Linux server and I’d like to restart my httpd server after making some changes to httpd.conf file. How do I restart httpd?

A. You can use service command to restart httpd. Another option is use /etc/init.d/httpd service script.

Login as root user and type the following commands:

Task: Start httpd server:

# service httpd start

Task: Restart httpd server:

# service httpd restart

Task: Stop httpd server:

# service httpd stop
Please note that restart option is a shorthand way of stopping and then starting the Apache HTTPd Server. You need to restart server whenever you make changes to httpd.conf file. It is also good idea to check configuration error before typing restart option:
# httpd -t
# httpd -t -D DUMP_VHOSTS
Sample output:

Syntax OK

Now restart httpd server:
# service httpd restart
Where,

• -t : Run syntax check for config files
• -t -D DUMP_VHOSTS : Run syntax check for config files and show parsed settings only for vhost.

/etc/init.d/httpd script

You can also use following command:
# /etc/init.d/httpd restart
# /etc/init.d/httpd start
# /etc/init.d/httpd stop

A note about Debian / Ubuntu Linux

Type the following command under Debian / Ubuntu Linux:
# /etc/init.d/apache2 restart
# /etc/init.d/apache2 stop
# /etc/init.d/apache2 start
You can also use service command under Debian / Ubuntu Linux:
# service apache2 restart
# service apache2 stop
# service apache2 start

from: www.cyberciti.biz

SSH:

Q. How do I monitor my ssh server with monit? How do I restart ssh server if it does not respond or dead due to any issues under Linux?

A. You can easily monitor Linux server or service such as OpenSSH (SSHD daemon) using monit utility.

Monitor SSH and Auto Restart If Died

Open your /etc/monitrc or /etc/monit/monitrc file:
# vi /etc/monit/monitrc
Append following code:
check process sshd with pidfile /var/run/sshd.pid
start program "/etc/init.d/ssh start"
stop program "/etc/init.d/ssh stop"
if failed port 22 protocol ssh then restart
if 5 restarts within 5 cycles then timeout

Save and close the file. Make sure you set /var/run/sshd.pid and /etc/init.d/ssh as per your Linux distribution. These values are valid for Debian / Ubuntu Linux. Restart monit to pickup the changes:
# /etc/init.d/monit restart

from: www.cyberciti.biz

Mysql:

Each distribution comes with a shell script (read as service) to restart / stop / start MySQL server. First login as root user and open shell prompt (command prompt).

First login as root user. Now type the following command as per your Linux distro:

A) If you are using mysql on RedHat Linux (Fedora Core/Cent OS) then use following command:

* To start mysql server:

/etc/init.d/mysqld start

* To stop mysql server:

/etc/init.d/mysqld stop

* To restart mysql server

 /etc/init.d/mysqld restart

Tip: Redhat Linux also supports service command, which can be use to start, restart, stop any service:

# service mysqld start
# service mysqld stop
# service mysqld restart

(B) If you are using mysql on Debian / Ubuntu Linux then use following command:

* To start mysql server:

/etc/init.d/mysql start

* To stop mysql server:

/etc/init.d/mysql stop

* To restart mysql server

/etc/init.d/mysql restart

from: theos.in

Qmail:

qmail-init(8) – Linux man page

Name

qmail-init – start/stop scripts for qmail

Synopsis

init.d/qmail [ start | stop | restart | status ]

init.d/qmtpd [ start | stop | restart | status ]

init.d/pop3d [ start | stop | restart | status ]

init.d/qmqpd [ start | stop | restart | status ]

init.d/qmtpd [ start | stop | restart | status ]

init.d/smtpd [ start | stop | restart | status ]

Description

These init scripts are responsible for starting and stopping the three main qmail services. init.d/qmail invokes qmail-start (the main qmail delivery agent), init.d/pop3d invokes qmail-popup, checkpassword, and qmail-pop3d (the POP3 server system for qmail) by way of tcpserver, init.d/qmqpd invokes qmail-qmqpd (the QMQP server for qmail — a specialized null-client protocol) by way of tpcserver, init.d/qmtpd invokes qmail-qmtpd (the QMTP server for qmail — a high-speed alternative to SMTP) by way of tcpserver, and init.d/smtpd invokes qmail-smtpd (the SMTP daemon for qmail) by way of tcpserver, as well as optionally invoking rblsmtpd if that package is installed.

These files typically reside in either /etc/rc.d/init.d (most systems using SysV-style init scripts) or /etc/init.d (Solaris).

Control Files

aliasempty

Default delivery instructions. Default: ./Mailbox. The contents of this file are used as the default delivery instructions for any legitimate local address that has either nonexistant or empty delivery instructions. See dot-qmail(5) for details on the contents. To emulate the typical sendmail and procmail combined configuration, install the dot-forward and procmail packages (and ensure they and preline are in the path), and put the following lines in this file: |dot-forward .forward
|preline procmail

antirbldomains

If antirbl is installed, this file contains a list of domains for which to disable RBL testing. Default: empty.

checkpassword

The password checking program for all systems that require one (currently only init.d/pop3d) Default: checkpassword.

concurrencypop3d

Maximum number of simultaneous inbound POP3 connections. Default: 20.

concurrencyqmqpd

Maximum number of simultaneous inbound QMQP connections. Default: 20.

concurrencyqmtpd

Maximum number of simultaneous inbound QMTP connections. Default: 20.

concurrencysmtpd

Maximum number of simultaneous inbound SMTP connections. Default: 20.

logger

The program that is to be used for message logging. Default: splogger. It is started in the /var/log directory. If the string contains {}, then it replaced with the name of the system being logged (such as qmail or pop3d), otherwise the system name is appended to the string. To use multilog ensure that a subdirectory in /var/log exists for each of the systems and put the following in this file: multilog -t {}

rbldomains

If rblsmtpd is installed, this file lists the RBL domain servers on which to do lookups. Default: rbl.maps.vix.com.

rbltimeout

If rblsmtpd is installed, this file sets the timeout value. Default: 60.

ulimitcpu

The maximum amount of CPU time an individual daemon process (pop3d, qmqpd, qmtpd, or smtpd) is allowed to consume before it is terminated, in seconds. Default: unlimited.

ulimitdata

The maximum data segment size of an individual daemon process, in kilobytes. Default: unlimited.

from: linux.die.net

 

How to Back Up and Restore a MySQL Database

If you’re storing anything in MySQL databases that you do not want to lose, it is very important to make regular backups of your data to protect it from loss. This tutorial will show you two easy ways to backup and restore the data in your MySQL database. You can also use this process to move your data to a new web server.

• Back up From the Command Line (using mysqldump)
• Back up your MySQL Database with Compress
• Restoring your MySQL Database
• Backing Up and Restoring using PHPMyAdmin

Back up From the Command Line (using mysqldump)

If you have shell or telnet access to your web server, you can backup your MySQL data by using the mysqldump command. This command connects to the MySQL server and creates an SQL dump file. The dump file contains the SQL statements necessary to re-create the database. Here is the proper syntax:

$ mysqldump –opt -u [uname] -p[pass] [dbname] > [backupfile.sql]

• [uname] Your database username
• [pass] The password for your database (note there is no space between -p and the password)
• [dbname] The name of your database
• [backupfile.sql] The filename for your database backup
• [–opt] The mysqldump option

For example, to backup a database named ‘Tutorials’ with the username ‘root’ and with no password to a file tut_backup.sql, you should accomplish this command:

$ mysqldump -u root -p Tutorials > tut_backup.sql

This command will backup the ‘Tutorials’ database into a file called tut_backup.sql which will contain all the SQL statements needed to re-create the database.

With mysqldump command you can specify certain tables of your database you want to backup. For example, to back up only php_tutorials and asp_tutorials tables from the ‘Tutorials’ database accomplish the command below. Each table name has to be separated by space.

$ mysqldump -u root -p Tutorials php_tutorials asp_tutorials > tut_backup.sql

Sometimes it is necessary to back up more that one database at once. In this case you can use the –database option followed by the list of databases you would like to backup. Each database name has to be separated by space.

$ mysqldump -u root -p –databases Tutorials Articles Comments > content_backup.sql

If you want to back up all the databases in the server at one time you should use the –all-databases option. It tells MySQL to dump all the databases it has in storage.

$ mysqldump -u root -p –all-databases > alldb_backup.sql

The mysqldump command has also some other useful options:

–add-drop-table: Tells MySQL to add a DROP TABLE statement before each CREATE TABLE in the dump.

–no-data: Dumps only the database structure, not the contents.

–add-locks: Adds the LOCK TABLES and UNLOCK TABLES statements you can see in the dump file.

The mysqldump command has advantages and disadvantages. The advantages of using mysqldump are that it is simple to use and it takes care of table locking issues for you. The disadvantage is that the command locks tables. If the size of your tables is very big mysqldump can lock out users for a long period of time.

Back up your MySQL Database with Compress

If your mysql database is very big, you might want to compress the output of mysqldump. Just use the mysql backup command below and pipe the output to gzip, then you will get the output as gzip file.

$ mysqldump -u [uname] -p[pass] [dbname] | gzip -9 > [backupfile.sql.gz]

If you want to extract the .gz file, use the command below:

$ gunzip [backupfile.sql.gz]

Restoring your MySQL Database

Above we backup the Tutorials database into tut_backup.sql file. To re-create the Tutorials database you should follow two steps:

• Create an appropriately named database on the target machine
• Load the file using the mysql command:

$ mysql -u [uname] -p[pass] [db_to_restore] < [backupfile.sql]

Have a look how you can restore your tut_backup.sql file to the Tutorials database.

$ mysql -u root -p Tutorials < tut_backup.sql

To restore compressed backup files you can do the following:

gunzip < [backupfile.sql.gz] | mysql -u [uname] -p[pass] [dbname]

If you need to restore a database that already exists, you’ll need to use mysqlimport command. The syntax for mysqlimport is as follows:

mysqlimport -u [uname] -p[pass] [dbname] [backupfile.sql]

Backing Up and Restoring using PHPMyAdmin

It is assumed that you have phpMyAdmin installed since a lot of web service providers use it. To backup your MySQL database using PHPMyAdmin just follow a couple of steps:

• Open phpMyAdmin.
• Select your database by clicking the database name in the list on the left of the screen.
• Click the Export link. This should bring up a new screen that says View dump of database (or something similar).
• In the Export area, click the Select All link to choose all of the tables in your database.
• In the SQL options area, click the right options.
• Click on the Save as file option and the corresponding compression option and then click the ‘Go’ button. A dialog box should appear prompting you to save the file locally.

Restoring your database is easy as well as backing it up. Make the following:

• Open phpMyAdmin.
• Create an appropriately named database and select it by clicking the database name in the list on the left of the screen. If you would like to rewrite the backup over an existing database then click on the database name, select all the check boxes next to the table names and select Drop to delete all existing tables in the database.
• Click the SQL link. This should bring up a new screen where you can either type in SQL commands, or upload your SQL file.
• Use the browse button to find the database file.
• Click Go button. This will upload the backup, execute the SQL commands and re-create your database.

—

Quoted from: www.webcheatsheet.com

Desktop vs. Browser – when to deploy applications for each

Since I talk so much about browser applications versus desktop applications, I thought it would be a good idea to blog about some thoughts I have regarding when to choose one delivery mechanism or the other. In a lot of ways, it isn’t even a matter of richness anymore. Most people associate “browser apps” with Ajax, but technologies like Flex and “WPF/E“, as well as XAML Browser Applications (XBAPs) all run in the browser and bring the richness of the desktop. So if it isn’t about richness, what is it about? I don’t think this is the final answer, but hopefully it spurs a conversation, and I’m hoping to cover this a bit in my panel at the Web 2.0 Expo.

5 Reasons to Deploy Applications in the Browser

• You need the barrier of entry to be low. Browsers are convenient, you browse to an address, and the application is right at your fingertips. When you want users to try something out, or get started quickly, a browser application is the way to go.
• You need a central place for deployment. With the browser model, you can store the application in one place, and when you update it, it’s updated everywhere. That’s convenient, and easy for users and administrators alike.
• You absolutely have to be cross platform. Adobe Apollo will probably make this obsolete down the road, but for right now, if you have to have a cross platform application, the browser is the way to go. There are browsers for devices, all major operating systems, and televisions. They may not all work the same, but they are cross platform.
• You want to take advantage of people’s “browser knowledge”. It’s safe to say that almost everyone knows how to use a browser. In some cases, building an application that takes advantage of that knowledge is good. Having back and forward buttons, having a URL to access, all of those are things people understand, and can be programmed to take advantage of.
• You know you won’t have access to machines. In some environments, users are restricted from downloading things on their machines, or you could need to access an application on a computer that isn’t yours. In that case, the browser is the way to go. It doesn’t leave (much) of a footprint, and you don’t have to worry about what privileges you have on the computer.

5 Reasons to Deploy Applications on the Desktop

• You want your application to be front and center for your users. Browsers crash, often times users have multiple tabs open and there’s a lot of clutter in the browser. When your application has to be accessible outside of that, a desktop application is the way to go.
• You want to take advantage of system resources. For raw power, nothing beats the full capabilities of the desktop. Hardware acceleration or anything taxing on the computer can be handled better by applications specifically programmed to take advantage of those. In the browser, you’re mostly stuck with that memory manager; outside you have more room.
• You’re building a “widget” application. Widgets are becoming bigger and bigger (in terms of capability) and you just can’t run a widget platform inside the browser. Widgets need to be accessible from the desktop where they can take up a small space and be easily moved around. The browser restricts that too much.
• You need to integrate closely with the desktop. This may sound like a no brainer, but if you want your application to feel like a desktop app to your users, that’s how it should be deployed. Do they need to be able to drag files to it from the desktop? Save things locally? See it in the add/remove programs area? Have a shortcut and icon in the Applications directory? If those are important to your brand or if having that functionality is important, the desktop is the way to go.
• You need a consistent user interface and/or brand. Deploying applications in the browser requires you work inside their interface. Oftentimes that means you have a two interfaces running side by side. You may also have to worry about things like toolbars or other browser addons that affect how your application looks and how your users interact with it. By deploying desktop applications, you have full control over the interface and brand. You can make sure your users see only what you want them to see.

There are two big omissions I wanted to note, security and offline access. For me, security was a bit of a toss up. On one hand, with desktop apps, your data is on your hard drive, so you know where it is. But that also leaves it open to spyware and viruses. I think storing data online is a bit more secure, even though someone else can potentially see your data. Offline access has gotten a lot of buzz lately, but it’s not just a desktop-only technology anymore. Companies like Dekoh, Zimbra, and Scrybe have found ways to take browser applications offline. It’s a very difficult thing to program, but they’ve done it, so I left offline access off the list.

So what did I miss? Are there things here that don’t belong? Any glaring omissions? Let me know.

—-

Quoted from: zdnet.com