Zabbix Installation on CentOS

1. Install all the necessary pieces

rpm -Uvh http://repo.webtatic.com/yum/centos/5/latest.rpm

yum --enablerepo=webtatic install ntp php php-bcmath php-gd php-mysql httpd mysql gcc

mysql-server mysql-devel net-snmp net-snmp-utils net-snmp-devel net-snmp-libs curl-devel mak

php-mbstring

2. Start the NTP Service

/etc/init.d/ntpd start

3. Download the below rpm file and install it

wget http://dag.wieers.com/rpm/packages/fping/fping-2.4-1.b2.2.el5.rf.i386.rpm

rpm -Uvh fping-2.4-1.b2.2.el5.rf.i386.rpm

chmod 7555 /usr/sbin/fping

4. Add zabbix user

useradd zabbix

5. Download zabbix and untar it.

wget http://downloads.sourceforge.net/project/zabbix/ZABBIX%20Latest%20Stable/1.8.9/zabbix-1.8.9.tar.gz?r=http%3A%2F%2Fwww.zabbix.com%2Fdownload.php&ts=1324895422&use_mirror=nchc

tar -zxvf zabbix-1.8.9.tar.gz

6. Start MySQL, and change the root password.

/usr/bin/mysqladmin -u root password pdl12345

7. Connect to DB using the newly created password

mysql -u root -ppdl12345

mysql> CREATE DATABASE zabbix;

mysql> GRANT DROP,INDEX,CREATE,SELECT,INSERT,UPDATE,ALTER,DELETE ON zabbix.* TO zabbix@localhost IDENTIFIED BY ‘zabbix@123’;

mysql> quit;

8. Create the DB Schema and Install server and client with the required setting

cd zabbix-1.8.9

cat create/schema/mysql.sql | mysql -u zabbix -pzabbix@123 zabbix

cat create/data/data.sql | mysql -u zabbix -pzabbix@123 zabbix

cat create/data/images_mysql.sql | mysql -u zabbix -pzabbix@123 zabbix

./configure –enable-server –prefix=/usr/local/zabbix –with-mysql –with-net-snmp –with-libcurl

make install

Compile the agent

./configure –enable-agent –prefix=/usr/local/zabbix

make install

Add the zabbix server and agent ports to your /etc/services file.

echo ‘zabbix_agent 10050/tcp’ >> /etc/services

echo ‘zabbix_trap 10051/tcp’ >> /etc/services

Copy the sample configs to /etc/zabbix for server and agentd.

mkdir /etc/zabbix

cp misc/conf/zabbix_agentd.conf /etc/zabbix

cp misc/conf/zabbix_server.conf /etc/zabbix

in /etc/zabbix/zabbix_server.conf, modify:

DBUser=zabbix

DBPassword=zabbix@123

in /etc/zabbix/zabbix_agentd.conf, modify:

Server=127.0.0.1,yourserveripaddress

Comment Hostname Parameter

cp misc/init.d/redhat/zabbix_agentd_ctl /etc/init.d/zabbix_agentd
cp misc/init.d/redhat/zabbix_server_ctl /etc/init.d/zabbix_server

in /etc/init.d/zabbix_agentd AND /etc/init.d/zabbix_server:

BASEDIR=/usr/local/zabbix

in /etc/init.d/zabbix_agentd (Note the # hash marks, they are necessary), add near the top, just below #!/bin/sh:

# chkconfig: 345 95 95
# description: Zabbix Agentd

in /etc/init.d/zabbix_server (again, note the # Hash marks, they are required), add near the top, just below #!/bin/sh:

# chkconfig: 345 95 95
# description: Zabbix Server

Configure automatic starting and stopping of services.

chkconfig –level 345 zabbix_server on

chkconfig –level 345 zabbix_agentd on

chkconfig –level 345 httpd on

chkconfig –level 345 mysqld on

chkconfig –level 0123456 iptables off

/etc/init.d/iptables stop

Note: I turn the iptables firewall OFF because my box is behind a firewall. You should consult with your network folks before turning off the firewall. At the very least you should poke holes for port 80, 10050, and 10051 in the firewall.

cp -r frontends/php /var/www/html/zabbix

in /etc/php.ini, modify:

max_execution_time = 300

max_input_time = 600

memory_limit = 256M

date.timezone = Africa/Lagos

post_max_size = 32M

Now start httpd service

/etc/init.d/httpd start

chmod 777 /var/www/html/zabbix/conf

Launch http://yourserveripaddress/zabbix inyour browser

For

http://www.muck.net/wp-content/uploads/2007/10/zabbix_prereq_small.jpg

Make Your Files Immutable Which Even Root Can't Delete

A cool tip on how you can make files on your system immutable. By immutable, I mean evenroot can't delete the files if he choose to. Linux ships with a tool called chattr which can be used for the purpose . 'chattr' is similar to the 'attrib' DOS equivalent tool but much more powerful and flexible.

To make your file (test_file) immutable

# chattr +i test_file

... You can only do it logged in as root. Here the +i option sets the immutable bit for the file. Once this bit is set, even root can't delete or tamper with the file.

If you want to unset the immutable flag, just run the following command:

# chattr -i test_file

You can check what are the attributes of a file by using the following command:

# lsattr test_file
----i--------  test_file

If the immutable flag is set, there will be an 'i' in the listing. This command is used by system administrators to restrict the users from changing a file in a particular way or even the administrator can by mistake delete a critical file because of a mis-typed command. But if the immutable flag is set, these mistakes can be avoided.

chattr can be used to set/unset many more file attributes. Like if you want to allow everybody to just append data to a file and not change already entered data, you can set the append bit as follows:

# chattr +a test_file

Now the test_file can only be opened in append mode for writing data. You can unset the append attribute as follows:

# chattr -a test_file

To know more about this very useful tool in the system administrator's forte, check the man page forchattr.

Determine how much RAM is currently being used per program

http://www.pixelbeat.org/scripts/ps_mem.py

Critical system files in Linux

In Linux, almost all configuration parameters are stored in ordinary text files. And there is a special location under which the configuration files are stored namely /etc. The following table lists all major configuration files found in Linux and their purpose.

Critical system files in Linux

File/Directory	Permissions	Description
/var/log/	751	Directory containing all log files.
/var/log/messages	644	System messages.
/etc/crontab	600	System wide crontab file.
/etc/syslog.conf	640	Syslog daemon configuration file.
/etc/logrotate.conf	640	Controls rotation of system log files.
/var/log/wtmp	660	Who is logged in now. Use who to view.
/var/log/lastlog	640	Who has logged in before. Use last to view.
/etc/ftpusers	600	List of users who cannot FTP to the machine.
/etc/passwd	644	List of system’s user accounts.
/etc/shadow	600	Contains encrypted account passwords.
/etc/pam.d	750	PAM configuration files.
/etc/hosts.allow	600	Access control file.
/etc/hosts.deny	600	Access control file.
/boot/grub/grub.conf	600	Boot configuration file for GRUB bootloader.
/etc/securetty	600	TTY interfaces that allow root logins.
/etc/shutdown.allow	400	Users allowed to ctrl-alt-del
/etc/security	700	System access security policy files.
/etc/rc.d/init.d/	750	Program startup files on Red Hat systems.
/etc/init.d/	750	Program startup files on Debian systems.
/etc/sysconfig	751	System and network config files on Red Hat.
/etc/ssh	750	Secure shell configuration files.
/etc/sysctl.conf	400	Contains kernel tunable options.

Free Up Cache Memory in Linux

In the past, I've been forced to do ridiculous things like cat a file larger than available RAM to /dev/null and edit gigabyte files which flood my cache with this data. Luckily, Linux kernels 2.6.16 and newer provide a mechanism to clear the inode, page, and dentry caches on demand avoiding all this headache. All you have to do is echo a value to the proc filesystem, and you're done.

To use /proc/sys/vm/drop_caches, just echo a number to it.

To free pagecache:
echo 1 > /proc/sys/vm/drop_caches

To free dentries and inodes:

echo 2 > /proc/sys/vm/drop_caches

To free pagecache, dentries and inodes:

echo 3 > /proc/sys/vm/drop_caches

As this is a non-destructive operation and dirty objects are not freeable, the user should run "sync" first!

This was originally found @ http://www.linuxinsight.com/proc_sys_vm_drop_caches.html

Screen Quick Reference

http://aperiodic.net/screen/quick_reference

Hadoop Link

http://www.michael-noll.com/tutorials/running-hadoop-on-ubuntu-linux-single-node-cluster/

http://www.michael-noll.com/tutorials/running-hadoop-on-ubuntu-linux-multi-node-cluster/

How To – Find Out Your Ubuntu Version Name

This is just a quick tip, and something I tend to need to do because I’m a bit absentminded and have one of the worst short-term memories out there. The version names for Ubuntu sometimes escape me. Maybe it’s because they are referred to by cute little ‘codenames’ instead of version numbers.

Type the following at the prompt:
cat /etc/lsb-release
It should output something similar to mine, which looks like this:
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=11.04
DISTRIB_CODENAME=Natty Narwhal
DISTRIB_DESCRIPTION="Ubuntu 11.04"

Not too hard to figure out that the line that says ‘DISTRIB_CODENAME’ is the one that tells you the name of your version. Fairly painless.

You can find it by executing the below command

cat /etc/issue

The file /etc/issue holds the version of Ubuntu installed on your system

Chapter 8. Configuring Firewalling

8.1 Overview of Firewalling

In this chapter we implement packet filtering to protect our Access Point and our local wired network. It is helpful to think of the wireless network as dirty just as we think of the Internet; We have little to no control over who uses the wireless network and for what purposes, so we do not trust it. Further, the data and systems we wish to protect are on our wired LAN.

The standard tool for packet filtering on modern Linux systems is called IPTABLES. It is a collection of kernel modules and userland tools which can be used to formulate complex firewalling solutions. More in-depth guides to iptables can be obtained from the netfilter homepage, the Linux 2.4 Packet Filtering HOWTO and of course the iptables manpage. IPTABLES is included in both Redhat kernels dealt with during this HOWTO. If you are using a different distribution or kernel that doesn't support IPTABLES, you will need to obtain or build a kernel that does.

Note that the IPTABLES configuration given in this chapter will be superceded by the NOCAT configuration outlined in Appendix B as NOCAT configures IPTABLES on the fly. Readers who intend to runNOCAT for HOTSPOTing on their Access Point can safely skip this section.


8.2 Example IPTABLES configuration file

There are a number of GUI tools for configuring IPTABLES, both free and commercial, but we will cut to the chase and edit the IPTABLES configuration file directly. As in other sections, presented here is an example configuration file which you can modify for your use, using the imbedded comments as a guide. In this case, lines beginning with a "#" are comments.

Note that this is a very simple IPTABLES configuration file. It has no facility for logging, reporting or Network/Port address translation. Outside of the core functionality required to make the various services on our Access Point available, nothing is catered for. Further, it assumes that NO traffic is to be allowed on to the LAN from the WLAN except for responses to LAN generated traffic, which may or may not suit your purposes. In short, you can use this example as the basis of your firewalling policy but will need to add to it or modify it extensively in order to make it suitable for use in your environment.

For Redhat, the IPTABLES configuration file is /etc/sysconfig/iptables - Which is used by the /etc/init.d/iptables startup script.

# Example /etc/sysconfig/iptables configuration file # # Turn on traffic filtering *filter # Set default policies :INPUT DROP [1:44] :FORWARD DROP [0:0] :OUTPUT ACCEPT [27040:2493902] # Accept all traffic from the loopback interface. -A INPUT -i lo -j ACCEPT # Accept legitimate responses to traffic we generate. -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT # Accept SSH connections from the wired network only. # Change this to your LANs IP network -A INPUT -s 192.168.5.0/255.255.255.0 -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT -A INPUT -s ! 192.168.5.0/255.255.255.0 -p tcp -m tcp --dport 22 -j DROP # Allow ICMP, though there is a case for disabling it on the WLAN interface. -A INPUT -s 192.168.5.0/255.255.255.0 -i eth0 -p icmp -j ACCEPT -A INPUT -s 10.0.0.0/255.0.0.0 -i wlan0 -p icmp -j ACCEPT # Allow inbound DNS requests from the wireless network. -A INPUT -i wlan0 -p udp --dport 53 -j ACCEPT -A INPUT -i wlan0 -p tcp --dport 53 -j ACCEPT # Allow inbound DNS responses from our ISPs DNS servers. # Change these to the IP addresses of your ISPs DNS servers. -A INPUT -s 0.0.0.0 -i eth0 -p udp -m state --state ESTABLISHED -m udp --sport 53 -j ACCEPT -A INPUT -s 0.0.0.0 -i eth0 -p tcp -m tcp --sport 53 -m state --state ESTABLISHED -j ACCEPT -A INPUT -s 1.1.1.1 -i eth0 -p udp -m state --state ESTABLISHED -m udp --sport 53 -j ACCEPT -A INPUT -s 1.1.1.1 -i eth0 -p tcp -m tcp --sport 53 -m state --state ESTABLISHED -j ACCEPT # Allow inbound DHCP from the Local wireless network (note: not from 10.0.0/8) # Change this to the network allocated for your use. -A INPUT -s 10.1.2.0/255.255.255.0 -i wlan0 -p udp --dport 67:68 --sport 67:68 -j ACCEPT # Allow inbound HTTP from the wireless network. Remove the "#" on the next line to enable. # -A INPUT -s 10.1.2.0/255.255.255.0 -i wlan0 -p tcp -m tcp --dport 80 -j ACCEPT # Allow inbound FTP from the entire wireless network. Remove the "#" on the next two lines to enable. # -A INPUT -d 10.1.2.0/255.255.255.0 -p tcp -m tcp --dport 21 -j ACCEPT # -A INPUT -d 10.1.2.1 -p udp -m state --state NEW,ESTABLISHED -m udp --dport 21 -j ACCEPT # Allow all related traffic to/from non-privileged ports. -A INPUT -p tcp -m tcp --sport 1024:65535 --dport 1024:65535 -m state --state RELATED,ESTABLISHED -j ACCEPT # Allow all traffic from the LAN to be forwarded to the WLAN. # Change this to your LANs IP network -A FORWARD -s 192.168.5.0/255.255.255.0 -i eth0 -o wlan0 -d 10.0.0.0/255.0.0.0 -j ACCEPT # Forward all legitimate responses to forwarded traffic. -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT # Make it all true. COMMIT # Completed on Thu Jan 30 18:35:03 2003

8.3 Testing IPTABLES

Now that our configuration file is in place, we can test firewalling. We do this by ensuring that IPTABLES starts correctly, checking that the necessary modules have loaded and testing that connectivity between systems on our networks is filtered as we intended.

8.3.1 Starting IPTABLES manually

We start up IPTABLES with the following command, which will use the /etc/init.d/iptables script to load the necessary kernel modules and set out firewalling rules by loading the entries we made in/etc/sysconfig/iptables in section 8.2 above;

[root@accesspoint root]# service iptables start

Which should produce the following output;

Flushing all current rules and user defined chains: [ OK ] Clearing all current rules and user defined chains: [ OK ] Applying iptables firewall rules: [ OK ]

Take note of any errors as they will give us hints as to what has gone wrong. More often than not they will be syntax errors in the configuration file. If not, we can need to check that the necessary modules have loaded.

8.3.2 Checking that the IPTABLES modules have loaded

The kernel needs to load a number of modules in order for the firewalling functionality we require to be supported. We can check that the necessary modules have loaded with the following command;

[root@accesspoint root]# lsmod

Ensuring that the following modules are present. (Note that modules irrelevant to IPTABLES have been omitted from this list)

ipt_REJECT 3992 0 (autoclean) iptable_filter 2444 1 (autoclean) ip_tables 15096 3 [ipt_state ipt_REJECT iptable_filter] ipt_state 1080 8 (autoclean) ip_conntrack 27272 1 (autoclean) [ipt_state]

If the various IPTABLES modules are not present we can try manually inserting them into the kernel with the following command, again taking note of any errors for clues as to what may have gone wrong;

[root@accesspoint root]# insmod ip_tables

8.3.3 Using the IPTABLES userspace command

In order to see a list of the running IPTABLES rules, insert or delete new ones and generally manage firewalling, we can use the /sbin/iptables command. Refer to the iptables manpage for further information. The following command dumps the current running rules used by the kernel.

[root@accesspoint root]# /sbin/iptables -L

Which should show output similar to the following;

Chain INPUT (policy DROP) target prot opt source destination ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT tcp -- 192.168.5.0/24 anywhere tcp dpt:ssh DROP tcp -- !192.168.1.0/24 anywhere tcp dpt:ssh ACCEPT icmp -- 192.168.5.0/24 anywhere ACCEPT icmp -- 10.0.0.0/8 anywhere ACCEPT udp -- anywhere anywhere udp dpt:domain ACCEPT tcp -- anywhere anywhere tcp dpt:domain ACCEPT udp -- 0.0.0.0 anywhere state ESTABLISHED udp spt:domain ACCEPT tcp -- 0.0.0.0 anywhere state ESTABLISHED tcp spt:domain ACCEPT udp -- 1.1.1.1 anywhere state ESTABLISHED udp spt:domain ACCEPT tcp -- 1.1.1.1 anywhere state ESTABLISHED tcp spt:domain ACCEPT udp -- 10.1.2.0/24 anywhere udp spts:bootps:bootpc dpts:bootps:bootpc ACCEPT tcp -- anywhere anywhere state RELATED,ESTABLISHED tcp spts:1024:65535 dpts:1024:65535 Chain FORWARD (policy DROP) target prot opt source destination ACCEPT all -- 192.168.5.0/24 10.0.0.0/8 ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED Chain OUTPUT (policy ACCEPT) target prot opt source destination

Note that the information displayed is how IPTABLES has translated our configuration file. This can at times be misleading as it leaves some details out. If in doubt, refer to the configuration file.


8.3.4 Other methods of testing

Further testing of firewalling can be achieved by testing connectivity from other systems on your wired and wireless networks. The NMAP port scanner is invaluable in this regard and I recommend that you use it, both from your Access Point and from systems on your networks. If you did not install NMAP during our initial Redhat installation in Chapter 3, you can download and install it.

Further testing of your firewalling setup can be achieved simply by attempting to ping between systems on your networks, or attempting to connect to services that you have running. For instance, you may like to check that wireless clients obtain IP configuration successfully from the Access Point via DHCP and that they can perform DNS lookups. You may also like to confirm that wireless clients cannot ping machines on your wired LAN but that machines on your LAN can ping wireless clients.

Security is always a major concern and it is over to you to audit your network and ensure that it is adequately protected on an on-going basis.


8.4 Enabling IPTABLES from startup

As we did with DHCPD, NAMED, ZEBRA and OSPFD in previous chapters, we need to turn on IPTABLES from boot using the setup utility. We add IPTABLES to our list of services that should start at boot time by adding an asterix beside the IPTABLES entry in the System services menu of setup as described in section 3.3