In a shell script – How do I round a decimal number (contained in a variable) to the nearest whole number?
var=2.5
echo $var|awk ‘{print int($1+0.5)}’
Output is 2
|
round a number
In a shell script – How do I round a decimal number (contained in a variable) to the nearest whole number?
|
I have Zimbra Collaboration Suite installed Now I wanted to integrate it to Open Directory for authentication purposes. The problem is though that Zimbra does not make this easy, especially when dealing with SSL certificates. Here’s what I did step by step
Install Zimbra
1. Download and install the Zimbra package,
1.1 Next, verify your DNS is setup correctly. The server you’re installing Zimbra onto must have a DNS record, this record must be the server’s hostname as well as the domain’s MX.
1.2 the via SSH run
/opt/zimbra/libexec/zmsetup.pl as ROOT
1.3 Zimbra will assume that the machine’s hostname is also its TLD. Which 99% of the time is not the case. You can enter your TLD when it asks.
2. Enter admin password (3, 4) Enter License (19) Return (r)
If your Zimbra server is installed onto the Open Directory Master or Replica, change the LDAP port to be 390 (1,3)
Apply Changes (a)
3. Import the Open Directory’s LDAP SSL certificate into Zimbra as a trusted certificate.
# Copy the appropriate OD’s ssl cert into the /tmp folder on the Zimbra Server. The default cert is located at /etc/certificates/Default.crt
# if using self-signed cert X.509 these files would be /etc/certs/ca.crt
# once copied run this command:
sudo keytool -import -keystore /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home/lib/security/cacerts -storepass changeit -alias LDAPAUTH -file /tmp/Default.crt
# erase the cert in /tmp
# restart zimbra sudo -u zimbra /opt/zimbra/bin/zmcontrol stop and then start
4. Navigate to https://servername:7071 in your web browser to enter the admin console of Zimbra
5. Configure Zimbra to use the external LDAP as its domain authentication method
# Expand domains arrow
# Select your domain and click configure authentication
# Select External LDAP
# Enter IP and select SSL
# for filter enter (&(objectClass=inetOrgPerson)(objectClass=posixAccount)(uid=%u))
# enter the LDAP base
# we are not using DN/Password, skip this step
# test the configuration by using testuser/password credentials
6. Configure Zimbra to use the external LDAP GAL
# Select configure GAL
# Select External
# ServerType – LDAP, enter your Open Directory Master IP, select SSL
# for filter enter (&(|(cn=*%s*)(sn=*%s*)))
# for autocomplete enter (|(uid=%s*)(givenname=%s*)(mail=%s*))
# enter the LDAP base – note the auto populated entry will be for the local ldap
# we are not using DN/Password, skip this step
# use GAL sync settings at default (click next)
# test the configuration by searching for a partial match on the user name – ie: if the username is “testuser”, search for “test” or first or last name of the test user, this data was entered into the info box in workgroup manager
# if test results are successful, click “Finish”
Provisioning Users
For manual batch user provisioning of Open Directory users to Zimbra:
# Enter all the accounts into a text file called userlist.txt with the following structure. Make sure you use the user’s shortname for the prefix in their email address
ca user1@host.tld “”
ca user2@host.tld “”
ca user3@host.tld “”
# Then dump that text file into the zmprov command as follows
sudo /opt/zimbra/zmprov < userlist.txt
For manually provisioning Open Directory users to Zimbra:
# SSH into Zimbra server
sudo /opt/zimbra/bin/zmprov ca user@domain.tld “”
Clamav update is required if one day support for certain versions of clamav terminated.
To be able to update Clamav in the Mail Server Zimbra actually not too difficult of origin according to the procedure, the following steps:
Download Clamav version on it or the most recent
The latest version now is Clamav 0.96, but here I will use the Clamav Clamav 0.95 instead of 0.94.
root@mail:~# wget http://files2.zimbra.com/downloads/clamav/ubuntu8/clamav-0.95.1.tgz
root@mail:~# tar -xf clamav-0.95.1.tgz
root@mail:~# mv clamav-0.95.1 /opt/zimbra
Then go to the folder where zimbra is:
root@mail:~# cd /opt/zimbra
root@mail:/opt/zimbra#
Before performing the update Clamav in Mail Server Zimbra, mail server zimbra we must stop system:
root@mail:/opt/zimbra# su – zimbra
zimbra@mail:~$ zmcontrol stop
zimbra@mail:~$ exit
root@mail:/opt/zimbra#
The next step is that we remove clamav Clamav existing to be replaced with a new version :
root@mail:/opt/zimbra# rm clamav
root@mail:/opt/zimbra# ln -s clamav-0.95.1 clamav
Then to check if Clamav has been replaced with the latest Clamav, please do the following:
root@mail:/opt/zimbra# ls -l clamav
And outputs are as follows :
lrwxrwxrwx 1 root root 13 2010-04-21 15:53 clamav -> clamav-0.95.1
Then we start again Zimbra functions :
root@mail:/opt/zimbra# su – zimbra
zimbra@mail:~$ zmcontrol start
zimbra@mail:~$ exit
root@mail:/opt/zimbra#
In order for Clamav to work with the normal new mail should we restart the zimbra server :
root@mail:/opt/zimbra# reboot
Use keytool to generate, import, and export certificates. By default, keytool creates a keystore file in the directory where it is run. You can find the keytool utility under the bin directory of java folder.
Note: – When you install Glassfish, it creates a default self-signed certificate as the server certificate. (localhost)
Type the following command to delete the default self-signed certificate by issuing the following command.
keytool -delete -alias s1as -keystore keystore.jks -storepass <store_passwd>
Steps 1:- Type the following command to create new certificate:
keytool -genkey -alias test
Fill all the information to create the certificate.
Enter keystore password: p@ssw0rd!
What is your first and last name?
[Unknown]: Chandra
what is the name of your organizational unit?
[Unknown]: CompanyName
what is the name of your organization?
[Unknown]: CompanyName
what is the name of your City or Locality?
[Unknown]: Gurgaon
What is the name of your State or Province?
[Unknown]: HR
What is the two-letter country code for this unit?
[Unknown]: IN
Is <CN=Chandra, OU=, O=CompanyName, L=Gurgaon, ST=HR, C=IN> correct?
[no]: yes
A certificate can be imported into a keystore using keytool. Type the following command to import the certificate:-
keytool -storepass my-keystore-password() -alias test -import -file test.cer
Steps:
Default days is 7 and cant not be set 0 day. You need to specify at least 1 day to create.
keytool -genkey -alias test –validity 1
Steps:
Follow up the first step
Steps:
Follow up the first step and give the invalid CN whatever you want to keep while ask the keytool utility during the creating of certificate.
Always generate the certificate in the directory containing the keystore and truststore files, by default domain-dir/config.
Open the Glassfish admin console in the web browser.
Login into glassfish admin console (http://localhost:4848), Default uid and password: admin and adminadmin
a) In the Admin Console tree, select the Application Server node.
b) Select JVM Settings.
c) Click the JVM Options tab.
d) On the JVM Options page, add or modify the following values in the Value field to reflect the new location of the certificate files:
| -Djavax.net.ssl.keyStore=${com.sun.aas.instanceRoot}/path/ks-name-Djavax.net.ssl.trustStore=${com.sun.aas.instanceRoot}/path/ts-name |
e) Where ks-name is the keystore file name and ts-name is the trust store file name.
f) Click Save.
g) Restart the Application Server if Restart Required displays in the console.
Here are the instructions for enabling GlassFish v2 as an SSL server when the application server is configured with the developer profile.
keytool -delete -alias s1as -keystore keystore.jks -storepass <store_passwd>
where <store_passwd> is the password for the keystore, for example, “mypass”. Note that s1as is the default alias of the GlassFish v2 keystore.
keytool -genkeypair -keyalg <key_alg>
-keystore keystore.jks -validity <val_days> -alias s1as
where <key_alg> is the algorithm to be used for generating the key pair, for example RSA, and <val_days> is the number of days that the certificate should be considered valid, for example, 365.
Note that in addition to generating a key pair, the command wraps the public key into a self-signed certificate and stores the certificate and the private key in a new keystore entry identified by the alias.
It’s important to ensure that the name of the certificate matches the fully-qualified hostname of your site. If the names don’t match, clients connecting to the server will see a security alert stating that the name of the certificate does not match the name of the site. You should notice that the name of the default self-signed certificate matches the fully-qualified hostname.
keytool -certreq -alias s1as -file <certreq_file>
-keystore keystore.jks -storepass <store_passwd>
where <certreq_file> is the file in which the CSR is stored, for example, s1as.csr, and <store_passwd> is the password for the keystore, for example, changeit.
When you import the certificate using the same original alias “s1as”, keytool treats it as a command to replace the original certificate with the certificate obtained as reply to a CSR.
s1as (self-signed):
Owner: CN=chandra, OU=CompanyName, O=CompanyNamr, L=Gurgaon , ST=Haryana, C=IN
Issuer: CN=Chandra, OU=CompanyName, O=CompanyName, L=Gurgaon, ST=Haryana, C=IN
Serial number: 472acd34
Valid from:
Xen is the open source virtualization solution .This blog is about installing a new Xen server on Ubuntu 10.04. Also I have the composite window manager on top of the Xen! With full 3D support!
To achieve this I do:
1- Install your Ubuntu Desktop 10.4 and upgrade your system;
1.1 – Install some packages:
aptitude install build-essential libncurses5-dev dpkg-dev debhelper fakeroot
2- Download and install a new kernel with dom0 pv_ops enabled:
sudo -s
cd /usr/src
git clone git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git linux-2.6-xen
cd linux-2.6-xen
git pull
git reset –hard
git checkout -b xen/stable origin/xen/stable
git pull
2.1 – Download the kernel config file attached to this mail (config-for-xen-2.6.32.10-pvops):
Copy the config file to the kernel source dir:
cp ~Downloads/config-for-xen-2.6.32.10-pvops /usr/src/linux-2.6-xen/.config
You can see the differences of my config file against the Lucid one:
diff /boot/config-2.6.32-17-generic ~Downloads/config-for-xen-2.6.32.10-pvops | vim -
…both are close to each other.
2.2 Configure, compile and install:
make menuconfig # Enable the dom0 support and the Xen backend/frontend/xenfs stuffs…
make
chmod g-s /usr/src -R # To avoid the error: “dpkg-deb: control directory has bad permissions 2755 (must be >=0755 and > /etc/modules
Now you can try your new kernel without Xen, if you want, it should work smootly.
3- Download and install the latest Xen:
Preparing your environment:
apt-get build-dep xen-3.3
aptitude install uuid-dev iasl texinfo
Download and compile:
cd /usr/src
hg clone -r 4.0.0-rc8 http://xenbits.xensource.com/xen-unstable.hg
cd xen-unstable.hg
make xen
make tools
make stubdom
make install-xen
make install-tools PYTHON_PREFIX_ARG=
make install-stubdom
update-rc.d xend defaults 20 21
update-rc.d xendomains defaults 21 20
4- Configuring your Grub2 through the file /etc/grub.d/40_custom:
—- cut here —-
#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries. Simply type the
# menu entries you want to add after this comment. Be careful not to change
# the ‘exec tail’ line above.
menuentry “Xen 4.0.0-rc8 / Ubuntu 10.4 kernel 2.6.32.10 pvops” {
insmod ext2
set root=(hd0,1)
multiboot (hd0,1)/xen-4.0.0-rc8.gz dummy=dummy
module (hd0,1)/vmlinuz-2.6.32.10 dummy=dummy root=/dev/mapper/HyperDeskVG01-tcmc–dell–lucid ro
module (hd0,1)/initrd.img-2.6.32.10
}
—- cut here —-
Don’t forget to change your “root=” option of your Linux!
Run update-grub again:
update-grub
5- Reboot into your new dom0!
reboot
6- Look if your Xen is up and running
xm list
xm info
.. if not:
/etc/init.d/xendomains stop
/etc/init.d/xend stop
/etc/init.d/xend start
/etc/init.d/xendomains start
xm list
xm info
Configuring a Kerberos 5 Server
To configure a basic Kerberos server, follow these steps:
1. Be sure that you have clock synchronization and DNS working on your server before configuring Kerberos 5. Pay particular attention to time synchronization between the Kerberos server and its various clients. If the server and client clocks are different by more than five minutes (this default amount is configurable in Kerberos 5), Kerberos clients will not be able to authenticate to the server. This clock synchronization is necessary to prevent an attacker from using an old Kerberos ticket to masquerade as a valid user.
You should set up a Network Time Protocol (NTP) compatible client/server network even if you are not using Kerberos. Red Hat Linux includes the ntp package for easy installation. See /usr/share/doc/ntp-<version-number>/index.htm for details on setting up Network Time Protocol servers and http://www.ntp.org/ for additional information on NTP.
2. Install the krb5-libs, krb5-server, and krb5-workstation packages on the dedicated machine which will run the KDC. This machine needs to be very secure — if possible, it should not run any services other than the KDC (Kerberos Server/Key distribution Center).
#yum install krb5-libs krb5-server krb5-workstation
If you would like to use a graphical user interface utility to administrate Kerberos, you should also install the gnome-kerberos package. It contains krb5, a GUI tool for managing tickets.
3. Edit the /etc/krb5.conf and /var/kerberos/krb5kdc/kdc.conf configuration files to reflect your realm name and domain-to-realm mappings. A simple realm can be constructed by replacing instances of EXAMPLE.COM and example.com with your domain name — being certain to keep uppercase and lowercase names in the correct format — and by changing the KDC from kerberos.example.com to the name of your Kerberos server. By convention, all realm names are uppercase and all DNS hostnames and domain names are lowercase. For full details on the formats of these files, see their respective man pages
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
default_realm = manoj.COM
dns_lookup_realm = false
dns_lookup_kdc = false
ticket_lifetime = 24h
forwardable = yes
[realms]
manoj.COM = {
kdc = manoj.com:88
admin_server = manoj.com:749
default_domain = manoj.com
}
[domain_realm]
.manoj.com = manoj.COM
manoj.com = manoj.COM
[appdefaults]
pam = {
debug = false
ticket_lifetime = 36000
renew_lifetime = 36000
forwardable = true
krb4_convert = false
}
4. Create the database using the kdb5_util utility from a shell prompt:
/usr/kerberos/sbin/kdb5_util create -s
5. The create command creates the database that will be used to store keys for your Kerberos realm. The -s switch forces creation of a stash file in which the master server key is stored. If no stash file is present from which to read the key, the Kerberos server (krb5kdc) will prompt the user for the master server password (which can be used to regenerate the key) every time it starts.
6. Edit the /var/kerberos/krb5kdc/kadm5.acl file. This file is used by kadmind to determine which principals have administrative access to the Kerberos database and their level of access. Most organizations will be able to get by with a single line:
*/admin@EXAMPLE.COM * replace EXAMPLE.COM with your domain name like manoj.COM
Most users will be represented in the database by a single principal (with a NULL, or empty, instance, such as joe@EXAMPLE.COM). With this configuration, users with a second principal with an instance of admin (for example, joe/admin@EXAMPLE.COM) will be able to wield full power over the realm’s Kerberos database. Once kadmind is started on the server, any user will be able to access its services by running kadmin on any of the clients or servers in the realm. However, only users listed in the kadm5.acl file will be able to modify the database in any way, except for changing their own passwords.
Note:
The kadmin utility communicates with the kadmind server over the network, and they use Kerberos to handle authentication. Of course, you need to create the first principal before you can connect to the server over the network to administer it. Create the first principal with the kadmin.local command, which is specifically designed to be used on the same host as the KDC and does not use Kerberos for authentication.
7. Type the following kadmin.local command at the KDC terminal to create the first principal:
#/usr/kerberos/sbin/kadmin.local -q “addprinc username/admin”
8. Start Kerberos using the following commands:
/sbin/service krb5kdc start
/sbin/service kadmin start
/sbin/service krb524 start
kadmind
The kadmind command starts the administrative server. This administrative server runs on Kerberos server that stores the Kerberos principal database and the policy database. The kadmind accepts password change request and remote requests to administer the information in these databases.
kadmind requires the following configuration files to be set for it to work:
kdc.conf
The KDC configuration file contains configuration information for the KDC and the KADM5 system.
keytab
kadmind requires a keytab containing the keys for the kadmin/admin and kadmin/changepw principals for every realm that kadmind will answer requests for. This admin keytab can be created with the kadmin.local. The location of the keytab is determined by the admin keytab configuration variable present in the kdc.conf file.
ACL file
kadmind’s access control list (ACL) restricts it as to which principals are allowed to perform administration actions. The path of the ACL file is specified via the acl_file configuration variable in the kdc.conf file.
These utilities provide a unified administration interface for the Kerberos database. Kerberos administrators use these utilities to create new users and services for the master database, and to modify information for the existing database entries.
Both the utilities provide for maintenance of Kerberos principals, policies, and service key tables (keytabs). These utilities exist as both a Kerberos client, ‘kadmin’and a local client, ‘kadmin.local‘.
The kadmin utility uses Kerberos authentication and an Remote Procedure Call (RPC) to operate securely from anywhere on the network.
The‘kadmin.local’ is intended to run directly on the KDC without any Kerberos authentication. Normal UNIX users cannot execute this command. Executing the kadmin.local command will display the kadmin.local prompt only if you are the root user.
Getting the kadmin to work
kadmin allows you to administer the Kerberos database remotely (and securely). If you just run kadmin, you may obtain an error message as shown below:
kadmin: Client not found in Kerberos database while initializing kadmin interface
To be able to use the kadmin interface, you need to register yourself as a database administrator.
Adding of users in the Kerberos database
Adding of users in the Kerberos database
/usr/kerberos/sbin/kadmin.local -q “addprinc manoj/admin”
On the KDC machine, in kadmin.local, you can add the administrator role:
kadmin.local: addprinc jar/admin
Enter password for principal “jar/admin@finance.bambi.com”: <your_password>
Re-enter password for principal “jar/admin@finance.bambi.com”: <your_password>
Principal “jar/admin@finance.bambi.com” created
kadmin.local: quit
Now you can access kadmin on the Kerberos server. For example,
/usr/kerberos/sbin/kadmin -p jar/admin
Password for jar/admin@manoj.COM:
In the Client Side
/usr/kerberos/bin/kinit -p manoj/admin
Password for manoj/admin@manoj.COM:
