Free Cookies for Linux & Windows

Originally posted on  Zabbix 1.4.4 from source on Debian Etch. This guide will walk you through installing Zabbix 1.4.4 from source on Debian Etch. 1.4.4 has many improvements over what is currently available in apt, and it’s not hard so you might as well do it this way. *Note: this walkthrough assumes that you will be running the zabbix database on the same machine as the frontend. You dont have to obviously, just do the mysql setup on whatever db server you are using and point the necessary things to it.

Required Packages: build-essential libmysqlclient-dev libssl-dev libsnmp-dev apache2 libapache2-mod-php5 php5-gd php5-mysql mysql-server

aptitude -y install build-essential libmysqlclient-dev libssl-dev libsnmp-dev apache2 libapache2-mod-php5 php5-gd php5-mysql mysql-server

Zabbix needs to have its own user and group so let’s create them (you need to do this as root).

groupadd zabbix
useradd -c ‘Zabbix’ -d /home/zabbix -g zabbix -s /bin/bash zabbix
mkdir /home/zabbix
chown zabbix:zabbix /home/zabbix

Let’s set up the MySQL database for zabbix.

mysql -p -u root
create database zabbix;
grant all on zabbix.* to ‘zabbix’@'localhost’ identified by ‘PASSWORD’;
quit;

Where PASSWORD is the password you want zabbix to connect to the database with.

Let’s go ahead and grab the zabbix source.

su – zabbix
wget http://internap.dl.sourceforge.net/sourceforge/zabbix/zabbix-1.4.4.tar.gz
tar zxvf zabbix-1.4.4.tar.gz
cd zabbix-1.4.4

Now let’s build the source and install zabbix_server and zabbix_agentd.

./configure –prefix=/usr –with-mysql –with-net-snmp –enable-server –enable-agent
make
exit
make install

We need to add the zabbix ports to /etc/services, and create some config files for zabbix.

echo ”
zabbix_agent 10050/tcp # Zabbix ports
zabbix_trap 10051/tcp” >> /etc/services
mkdir -p /etc/zabbix
chown -R zabbix:zabbix /etc/zabbix
cp misc/conf/zabbix_* /etc/zabbix
vim /etc/zabbix/zabbix_agentd.conf

ensure Server=127.0.0.1

vim /etc/zabbix/zabbix_server.conf

max_execution_time = 300
date.timezone = UTC
ensure DBHost=localhost or your db host
ensure DBName=zabbix
ensure DBUser=zabbix
ensure DBPassword=ZABBIX_PASSWORD

where ZABBIX_PASSWORD is the password you set when creating db.

The zabbix package has init scripts for Debian and they only need minor modification to get them working so let’s use them.

cp /home/zabbix/zabbix-1.4.4/misc/init.d/debian/* /etc/init.d/

Now modify both of those scripts changing

DAEMON=/home/zabbix/bin/${NAME}

to

DAEMON=/usr/sbin/${NAME}

Great; now we just need to get the database schema loaded, and then we need to set up the frontend. Let’s load the database schema first.

mysql -u root -p zabbix < /home/zabbix/zabbix-1.4.4/create/schema/mysql.sql
mysql -u root -p zabbix < /home/zabbix/zabbix-1.4.4/create/data/data.sql
mysql -u root -p zabbix < /home/zabbix/zabbix-1.4.4/create/data/images_mysql.sql

Great; now it’s just the frontend left. I like to put all of my webaps down in /var/www.

mkdir -p /var/www/zabbix
cp -R /home/zabbix/zabbix-1.4.4/frontends/php/* /var/www/zabbix/
chown -R zabbix:zabbix /var/www/zabbix/*

Create /etc/apache2/sites-available/zabbix with the following content:

<virtualhost>
ServerName zabbix.fqdn.tld
DocumentRoot /var/www/zabbix
<directory>
Options FollowSymLinks
AllowOverride None
</directory>
</virtualhost>

I disable the default site, and enable the zabbix site with a2ensite:

a2ensite zabbix
a2dissite default

Just a few minor edits in /etc/php5/apache2/php.ini:

max_execution_time = 300
date.timezone = UTC

Restart apache, zabbix-server, and zabbix-agent and you should be ready to rock and roll. You will need to browse to your zabbix frontend and complete the web-driven install which should be easy enough.

/etc/init.d/apache2 restart
/etc/init.d/zabbix-server start
/etc/init.d/zabbix-agent start
update-rc.d zabbix-server default
update-rc.d zabbix-agent default

* adapted and updated from http://www.howtoforge.com/zabbix_network_monitoring
Zabbix 1.4.4 from source on Debian Etch

Thanks to petey5000 for catching several typos.

Using a Samba Fileserver authenticating users against an Active Directory Domain Controller

Goal: Using a Linux (Debian 3.1, sarge) as a Fileserver for a Windows Network
To do this the Linux machine will access the Windows Domain Controller to get username and passwords. This is done using the winbind daemon. The daemon will also map linux-userids and groups to windows-sids (A windows Account has a unique SID that will differ even if you recreate an account with the same name).
Software

Used Software: Debian, Samba 3, Kerberos Kerberos packages:

Samba packages:apt-get install samba-common samba winbind smbclient
Utility packages

List of package version at the time of writing

krb5-config 1.6
krb5-user 1.3.6-2sarge2
libkrb53 1.3.6-2sarge2
libpam-krb5 1.0-12
samba-common 3.0.14a-3
samba 3.0.14a-3
winbind 3.0.14a-3
smbclient 3.0.14a-3

Configuration
Kerberos

Kerberos Configuration sits in /etc/krb5.conf, we add a default_realm and a server to the realm (write Uppercase Text also in uppercase).# file /etc/krb5.conf [libdefaults] default_realm = MY.ACTIVE.DIRECTORY ... [realms] MY.ACTIVE.DIRECTORY = { kdc = dc1.active.directory kdc = dc2.active.directory kdc = dc3.active.directory ... admin_server = dc1.active.directory } ...

Now we can check if we can Authenticate a user against the Active Directory debian:~# kinit administrator Password for administrator@MY.ACTIVE.DIRECTORY debian:~#

Winbind

The Winbind Daemon will map users and groups from the Active Directory to Linux. To do this we will tell winbind which ID-Range and which prefix it should use. The mapping is set up on use and stored in a file-database in the samba lock-dir /var/lib/samba/winbindd_idmap.tdb

The Configuration sits in the smb.conf # file /etc/samba/smb.conf [global] workgroup = ADGROUP security = ADS realm = MY.ACTIVE.DIRECTORY winbind separator = + idmap uid = 10000-20000 idmap gid = 10000-20000 winbind enum users = yes winbind enum groups = yes auth methods = winbind ... # the share we will use to test it, make sure path is # valid and writeable [testshare] comment = Test Share using Active Directory read only = no path = /data/test valid users = @"ADGROUP+domain users"

Start the winbind daemon (/etc/init.d/winbind start) and now we can list the users from the Active Directory debian:~# wbinfo -u ADGROUP+administrator ADGROUP+guest ADGROUP+chandel ...

Samba

Next we will get a kerberos Ticket and join our Server to the active directory debian:~# kinit administrator Password for administrator@MY.ACTIVE.DIRECTORY debian:~# net ads join Using short domain name -- ADGROUP Joined 'DEBIAN' to realm 'MY.ACTIVE.DIRECTORY'

PAM
So far so good. We can authenticate using kerberos tickets and Samba knows how to get userids and groups. But we also need to tell the operating system about the userids. This is done using PAM. We tell PAM that samba requires authentication and account from winbind.

# File /etc/pam.d/samba auth required /lib/security/pam_winbind.so account required /lib/security/pam_winbind.so
And we tell the system that it can get information about userdata (id, name, homedir, etc.) not only from /etc/passwd but also from winbind

# File /etc/nsswitch.conf ... passwd: compat winbind group: compat winbind shadow: compat ...
Test it by listing the accounts known to the system debian:~# getent passwd root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/bin/sh bin:x:2:2:bin:/bin:/bin/sh ... ADGROUP+administrator:x:10001:10000:Administrator:/home/ADGROUP/administrator:/bin/false ADGROUP+guest:x:10002:10001:Guest:/home/ADGROUP/guest:/bin/false ...
Test

Test it using our own server as a linux client. We will get a ticket, and connect to the share using this ticket. Than we place a file there and check in the filesystem who owns the file. debian:~# kinit administrator Password for administrator@MY.ACTIVE.DIRECTORY debian:~# touch hello_world.txt debian:~# smbclient //fileservername/testshare -k OS=[Unix] Server=[Samba 3.0.14a-Debian] smb: \> put hello_world.txt putting file hello_world.txt as \hello_world.txt (0.0 kb/s) (average nan kb/s) smb: \> quit debian:~# ls -l /data/testshare/hello_world.txt -rwxr--r-- 1 ADGROUP+administrator ADGROUP+domain users 0 2005-07-22 13:37 /data/test/hello_world.txt debian:~#
Hints
Kerberos relies on synchronized time between client (linux box) and Server (Domain Controller). Keep your machines in sync using ntpd or ntpdate

The superuser is a privileged user with unrestricted access to all files and commands. The superuser has the special UID (user ID) 0. You need to become super user (root) only when tasks need root permissions. Here is how to become super user:

1) At shell prompt type su and press enter key, when prompted for password supply root user password:
$ su
password:
#

2) To exit super user status type exit or press CTRL+D
# exit>
$

Please note that if you get an error su: Sorry for normal user account. Following workaround needed to get rid of this problem/error:

1) For security, reason FreeBSD only allows su to root user, if user is member of wheel group. Wheel group is a special group for administration purpose. Add your normal user to this group using pw command using following:
# pw user mod username -G wheel

2) So to add user vivek to group wheel run command as follows:
# pw user mod vivek -G wheel
# groups vivek
vivek wheel

3) Now su will work for vivek user.

You can disable this behavior complete for all users (not recommended until and unless you trust ALL of users):
1) Open pam configuration file for su using text editor:
# vi /etc/pam.d/su

2) Look for following line and comment it out:
Line:
auth requisite pam_wheel.so no_warn auth_as_self noroot_ok exempt_if_empty
Replace with:
#auth requisite pam_wheel.so no_warn auth_as_self noroot_ok exempt_if_empty

3) Now all users can use su command.

You can disable a user’s account in the following different ways:

First Method
Open /etc/passwd file and find the line containing the user’s name.

# vi /etc/passwd

Or if you are on a system used by lots of people, there is a very secure form of opening the /etc/passwd file for editing :

# vipw

… which also opens the /etc/passwd file for editing in the vi editor – but in a more secure manner. #FILE: /etc/passwd ... ravi:x:500:500:Ravi Kumar:/home/ravi:/bin/bash ...</strong>
Now change the shell /bin/bash to /sbin/nologin . #FILE: /etc/passwd ... ravi:x:500:500:Ravi Kumar:/home/ravi:/sbin/nologin ...
Save and exit the file.

Second Method
Enter /etc/passwd file and move to the line containing the user’s name. Now enter a ‘!’ (bang) or ‘*’ (asterisk) just before the ‘x’ in the second field. Save and exit the file.
Note: The fields in the file /etc/passwd are separated by ‘:’ (colons) . #FILE: /etc/passwd ... ravi:*x:500:500:Ravi Kumar:/home/ravi:/bin/bash ...

Note: If you are not using shadow passwords (highly unlikely), you will have the password in encrypted format in the second field instead of an x. Unlocking the account is the reverse of what you did above.
Important: One guy told me that if you use the above method, a disabled user can login through the network using SSH. I have not checked it out though.

Third Method
You can use the command chage to lock a user’s account. You do this by changing the expiry date to any date before the current date. # chage -E 2005-10-01 ravi

The above command will set the expiry date of ravi’s account to ‘Oct 1st 2005′ which is a previous date. So when the next time ravi tries to login to his account, he will get the message that his account is disabled.
Note: For chage to work, you should be using shadow passwords (most distros use this by default). You can re-enable the user’s account by running the same command but changing the date to a value greater than the current date.

Fourth Method
Execute the following command:

This will lock ravi's account. Now to unlock the account, do:

Check the logs
All failed logins will be audited and logged to the file /var/log/messages. To see who all have unsuccessfully tried to login to their account, try the following:

Also if you have a file called /var/log/faillog check that out too. It contains a history of all failed login details. This file is used when you use PAM (Pluggable Authentication Modules) for enforcing password policies.

You can change the default password policies by editing the file /etc/login.defs . But any changes will be applicable to only to those user accounts created after the modification of the file.