Saturday, March 15, 2008

enable firewall


lokkit command

The lokkit command can be run at any time to change the security settings of Firewall installed on your system. To run this command you must first login as root or use the “su” command. If you are already super user on your Linux system start the lokkit command as follows:

/usr/sbin/lokkit

or to use the su command from a non-super user account as follows:

su –c “/usr/sbin/lokkit”

The lokkit command allows you to either enable or disable the Firewall. The first step if it is not already enabled is to enable it. Use the “Tab” key to move around and the “Space” key to select the “Enabled” option.

The second step is configure the Firewall. Use the Tab key to move the “Configure” button and press the “Space” key.

On the configuration screen simply select the service types that you want to support. Based on your selections lokkit will configure the Firewall to allow access to the appropriate ports. The services listed are HTTP, FTP, SSH, Telnet and Mail (SMTP). You can also specify other ports you wish to open on the Firewall in the “other ports” section.

The lokkit command also provides the option of specifying trusted devices on the "Configure" screen. In summary, it is possible to have more than one network device installed on a Linux system. In this scenario it might be that one device is connected to a trusted and secure network while the other is connected to a network that is connected to the outside world in some way (perhaps through a router or firewall to a broadband connection). The firewall feature allows you to disable the firewall settings for any connections coming in from the device connected to the trusted or secure network while applying the firewall rules to device connected ot the untrusted network.

Friday, March 7, 2008

PostgreSQL configuration



Login to the operating system as a User who has rights to create a database. If you haven't set this up yet, as user postgresql, run the createuser command and give the new User privileges to create databases.

Create the database:

createdb -E UNICODE calendar



  1. Load the database schema:

    psql calendar <>
  2. You will need to edit the postgresql.conf file. On RedHat Linux, this file is in the /var/lib/pgsql/data directory. On FreeBSD, this file is in /usr/local/pgsql/data. Change the line:

    #tcpip_socket=false

    to read

    tcpip_socket=true
  3. Restart the PostgreSQL Service.
  4. Copy the JDBC Driver files to your application server's path, or the WEB-INF/lib directory.
  5. Edit the pg_hba.conf file if necessary. To test if this is necessary, run the command:

    psql -h calendar

    If the connection is refused, you will need to add the appropriate permissions entries to PG_HBA.CONF. It may also be necessary to edit the startup script for postmaster to ensure that it is listening on TCP/IP sockets. Refer to the man page for postmaster for more information on startup options.
  6. Edit the configuration.properties file, putting in the configuration entries for your database.

DBObjectClass=com.MHSoftware.db.support.PostgreSQLDB
JDBCConnectString=jdbc\:postgresql\://localhost\:5432/calendar
JDBCUserID=calendar
JDBCPassword=calendar
JDBCDriver=org.postgresql.Driver

Apache Configuration Files:

  • /etc/httpd/conf/httpd.conf: is used to configure Apache. In the past it was broken down into three files. These may now be all concatenated into one file. See Apache online documentation for the full manual.
  • /etc/httpd/conf.d/application.conf: All configuration files in this directory are included during Apache start-up. Used to store application specific configurations.
  • /etc/sysconfig/httpd: Holds environment variables used when starting Apache.

Basic settings: Change the default value for ServerName www.<your-domain.com>

Giving Apache access to the file system: It is prudent to limit Apache's view of the file system to only those directories necessary. This is done with the directory statement. Start by denying access to everything, then grant access to the necessary directories.

Deny access completely to file system root ("/") as the default:

 

Options None
AllowOverride None

Grant access to a user's directory:

   
AllowOverride None
order allow,deny
allow from all
Options Indexes Includes FollowSymLinks

OR use the statement UserDir public_html which does this by default for every user account at $HOME/public_html. Change to a comment (add "#" at beginning of line) from Fedora Core default UserDir disable. Also use SELinux command: setsebool httpd_enable_homedirs true

File permissions: The Apache web server daemon must be able to read your web pages in order to feed thier contents to the network. Use an appropriate umask and file protection. This works: chmod ugo+r -R public_html
One may also use groups to control permisions. See the YoLinux tutorial on managing groups.

[Potential Pitfall]: If the Apache web server can not access the file you will get the error "403 Forbidden" "You don't have permission to access file-name on this server." Note the default permissions on a user directory when first created with "useradd" are:

drwx------ 3 userx userx
You must allow the web server running as user "apache" to access the directory if it is to display pages held there. Fix with command: chmod ugo+rx /home/userx
drwxr-xr-x 3 userx userx

apache http web server configuration


This tutorial is for the Apache HTTP web server (Version 1.3 and 2.0). for a list of other web servers for the Hyper Text Transport Protocol.

The Apache configuration file is: /etc/httpd/conf/httpd.conf

Web pages are served from the directory as configured by the DocumentRoot directive. The default directory location is:

  • Red Hat 7.x-9, Fedora Core, Red Hat Enterprise 4, CentOS 4: /var/www/html/
  • Red Hat 6.x and older: /home/httpd/html/
  • Suse 9.x: /srv/www/htdocs/
  • Ubuntu (dapper 6.06) / Debian: /var/www/html
The default home page for the default configuration is index.html. Note the pages should not be owned by user apache as this is the process owner of the httpd web server daemon. If the web server process is comprimised, it should not be allowed to alter the files. The files should of course be readable by user apache.

Apache may be configured to run as a host for one web site in this fashion or it may be configured to serve for multiple domains. Serving for multiple domains may be achieved in two ways:

  • Virtual hosts: One IP address but multiple domains - "Name based" virtual hosting.
  • Multiple IP based virtual hosts: One IP address for each domain - "IP based" virtual hosting.
The default configuration will allow one to have multiple user accounts under one domain by using a reference to the user account: http://www.domain.com/~user1/. If no domain is registered or configured, the IP address may also be used: http://XXX.XXX.XXX.XXX/~user1/.

[Potential Pitfall] The default umask for directory creation is correct by default but if not use: chmod 755 /home/user1/public_html

[Potential Pitfall] When creating new "Directory" configuration directives, I found that placing them by the existing "Directory" directives to be a bad idea. It would not use the .htaccess file. This was because the statement defining the use of the .htaccess file was after the "Directory" statement. Previously in RH 6.x the files were separated and the order was defined a little different. I now place new "Directory" statements near the end of the file just before the "VirtualHost" statements.

For users of Red Hat 7.1, the GUI configuration tool apacheconf was introduced for the crowd who like to use pretty point and click tools.

Files used by Apache:

  • Start/stop/restart script:
    • Red Hat/Fedora/CentOS: /etc/rc.d/init.d/httpd
    • SuSE 9.3: /etc/init.d/apache2
    • Ubuntu (dapper 6.06) / Debian: /etc/init.d/apache2
  • Apache main configuration file:
    • Red Hat/Fedora/CentOS: /etc/httpd/conf/httpd.conf
    • SuSE: /etc/apache2/httpd.conf
      (Need to add directive: ServerName host-name)
    • Ubuntu (dapper 6.06) / Debian: /etc/apache2/apache2.conf
  • Apache suplementary configuration files:
    • Red Hat/Fedora/CentOS: /etc/httpd/conf.d/component.conf
    • SuSE: /etc/apache2/conf.d/component.conf
    • Ubuntu (dapper 6.06) / Debian:
      • Virtual domains: /etc/apache2/sites-enabled/domain
        (Create soft link from /etc/apache2/sites-enabled/domain to /etc/apache2/sites-available/domain to turn on)
      • Additional configuration directives: /etc/apache2/conf.d/
      • Modules to load: /etc/apache2/mods-available/
        (Soft link to /etc/apache2/mods-enabled/ to turn on)
      • Ports to listen to: /etc/apache2/ports.conf
  • /var/log/httpd/access_log and error_log - Red Hat/Fedora Core Apache log files
    (Suse: /var/log/apache2/)

Start/Stop/Restart scripts: The script is to be run with the qualifiers start, stop, restart or status.
i.e. /etc/rc.d/init.d/httpd restart. A restart allows the web server to start again and read the configuration files to pick up any changes. To have this script invoked upon system boot issue the command chkconfig --add httpd. See Init Process Tutorial for a more complete discussion.

Also Apache control tool: /usr/sbin/apachectl start

Apache Control Command: apachectl:

Red Hat / Fedora Core / CentOS: apachectl directive
Ubuntu dapper 6.06 / Debian: apache2ctl directive
Directive Description
start Start the Apache httpd daemon. Gives an error if it is already running.
stop Stops the Apache httpd daemon.
graceful Gracefully restarts the Apache httpd daemon. If the daemon is not running, it is started. This differs from a normal restart in that currently open connections are not aborted.
restart Restarts the Apache httpd daemon. If the daemon is not running, it is started. This command automatically checks the configuration files as in configtest before initiating the restart to make sure the daemon doesn't die.
status Displays a brief status report.
fullstatus Displays a full status report from mod_status. Requires mod_status enabled on your server and a text-based browser such as lynx available on your system. The URL used to access the status report can be set by editing the STATUSURL variable in the script.
configtest
-t
Run a configuration file syntax test.