среда јун 17, 2009

WARNING: Time-of-day chip unresponsive; dead batteries?

  While working on a creation of the Web Space Server 10 Virtual Template, I have bumped on a quite annoying OpenSolaris bug which produced a chain of quite unexpected results.


  The mentioned bug occurs on OpenSolaris 2008.11 while runing as a guest OS on VMWare 3.5 ESX Update 3. The first time the image is booted evrything works fine, while on the next reboot(s) the error message


WARNING: Time-of-day chip unresponsive; dead batteries? 

is observed. The reason is, the first time OpenSolaris is booted, a new file with extension .nvram is created; it represents CMOS settings and it is filled with default values. On the following boot, the changes to CMOS are persisted by writting to the file, except that OpenSolaris touches a register which causes VMWare to misbehave. This is fixed in VMWare ESX 3.5 Update 4, but if you happen to bump on this issue and feel reluctant to update, then the solution is simply to remove the .nvram file.


The main impact of this bug is the system time which is reset to the January 1st 1970, which causes extremely wierd side effects on the system. In my case I learnt it was not possible to deploy Web Space Server 10 if the installation files had a date in the future. :-) 



среда мар 28, 2007

SSL setup from CLI

The following text is based on the documentation from http://docs.sun.com/source/816-6698-10/ssl.html

This is something I never had an opportunity to do often, but whenever I did, I had to dig throughout heaps of notes and documents to find what I needed. Namely, if you want to set up Directory Server 5.2 for testing/piloting/playing purposes, SSL would definitely be something you would want to play with. However, not having certificate authority to generate certificates would certainly make it a lot harder for you to get the basic setup up and running.


Thing to be done first is to create the certificate database for DS by using certutil:


certutil -N -d ServerRoot/alias -P slapd-ServerID- 


Now we need to make a certificate request:


certutil -R -s "cn=serverName,ou=division,o=company,l=city,st=state,c=country" -a -d ServerRoot/alias -P slapd-serverID- -o cert.req


This will save the certificate request into file cert.req. At this point you should send the file to your certificate authority to sign it and to produce the actual certificate. Apart from the certificate for the server, the CA has to provide you root certificate of it's own and/or certificate chain so you could trust it. Importing is as follows:


certutil -A -n "certificateName" -t "u,," -a -i certFile -d ServerRoot/alias -P slapd-serverID- 

and for root CA:


certutil -A -n "CAcertificateName" -t "trust,," -a -i certFile -d ServerRoot/alias -P slapd-serverID-

where trust is one of the following:


  • T - This CA is trusted to issue client certificates. Use this code if your LDAP clients perform certificate-based client authentication by presenting certificates issued by this CA.
  • C - This CA is trusted to issue server certificates. Use this code if your server will play a replication supplier or chaining multiplexor role over SSL with another server that has a certificate issued by this CA.
  • CT - This CA is trusted to issue both client and server certificates. Use this code if both cases above apply to this CA.


In case you are playing with a test server and you do not have a CA, you can create a self-signed certificate and use it as CA:


certutil -S -x -s "cn=CA" -n ca -t "TC,,," -1 -2 -5 -d ServerRoot/alias -P slapd-serverID-



In case the certificate request file is not in ASCII format (as it should be if the above command was used to generate it) then from the following command -a should be removed:


certutil -C -a -i cert.req -o node1.crt -c ca -d ServerRoot/alias -P slapd-serverID-



Now you can add the generated certificate:


certutil -A -i node1.crt -n server -t "P,P,P" -d ServerRoot/alias -P slapd-serverID-



At this point, SSL database should be ready to be used. Next thing to follow is to reconfigure DS to use SSL. Edit DS configuration to enable SSL either by manually chaning dse.ldif or by LDIF. If you chose to edit dse.ldif file do not forget to shut down DS first! Either way, the LDIF file should look like this:


dn: cn=config
changetype: modify
nsslapd-security: on

dn: cn=encryption,cn=config
changetype: modify
nsSSL3: on
nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5,+rsa_des_sha,+rsa_fips_des_sha,
+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fortezza_rc4_128_sha,+fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,
+tls_rsa_export1024_with_des_cbc_sha
nsKeyfile: alias/slapd-nis-key3.db
nsCertfile: alias/slapd-nis-cert7.db

dn: cn=RSA,cn=encryption,cn=config
changetype: add
nsSSLToken: internal (software)
nsSSLPersonalitySSL: server-cert
nsSSLActivation: on
objectClass: top
objectClass: nsEncryptionModule
cn: RSA




In order for DS to start automatically you need to edit ServerRoot/alias/slapd-serverID-pin.txt and put the following content:


Internal (Software) Token:password


Now you can start your DS service. From now on DS should be listening also for SSL connections. It is important to note that the approach with self-signed certificates would work only with a single DS instance. For multiple instance s you would have to export CA certificate and import it to other DS instances. This is easily achievable with pk12util. For example:


pk12util -d ServerRoot/ -P slapd-nis- -o ca.crt -n ca

уторак мар 27, 2007

Indexing via CLI

In regards to the previous post, another task that you would want automated is indexing. Although reindexing is not an bigger issue, adding new indexes might be more tricky if you don't have GUI. With Sun Java System Directory Server 6.0 is not such an issue since it comes with nice CLI tools, but version 5.2 requires reconfiguring using LDIF if the GUI is not available. The actual LDIF is quite simple:


dn: cn=$ATTRIBUE,cn=index,cn=$BACKEND_DB,cn=ldbm database,cn=plugins,cn=config
changetype: add
objectClass: top
objectClass: nsIndex
cn: $ATTRIBUE
nsIndexType: pres
nsIndexType: eq
nsIndexType: sub
nsSystemIndex: false


$ATTRIBUTE - name of the attribute that you want to have indexed;

$BACKEND_DB - backend database which holds the suffix which will be indexed, e.g. by default backend database is "userRoot" for the root suffix;

nsIndexType - specifies the type of the index - it could be: pres(ence), eq(uality), sub(string) and approx(imate). If nsIndexType is left empty, it means all index types would be created for this attribute.

UPDATE:

In response to Ludovic's comment below, I need to add a few notes. As Ludovic mentioned, and I failed stress it, this will only configure the indexes without actually creating them. The reindexing is easily performed from the CLI by running db2index\* tool, hence no additional toying with LDIF is needed.

Thanks for drawing my attention!

понедељак мар 26, 2007

MMR setup from CLI

Quite often I was in position which required automated configuration of multi-master replication on Sun Java Systems Directory Server 5.2, but I never got the chance to properly document it in a cheat-sheet form for the future reference.

If we would assume we have two DSAs, the process would be the following:

  • on both servers
    1. enable changelog on both servres;
    2. configure replication settings;
    3. set replication manager password;
    4. create replication agreements, and
  • on the primary master
    1. initialise the secondary master.

Here are the LDIF templates for each of the steps:

  • enabling changelog:

    dn: cn=changelog5, cn=config
    changetype: add
    objectclass: top
    objectclass: extensibleObject
    cn: changelog5
    nsslapd-changelogdir: $PATH_TO_CHANGELOG_DB
    

    $PATH_TO_CHANGELOG_DB - filesystem path where changelog database should be kept

  • replication settings:

    dn: cn=replica, cn=$SUFFIX, cn=mapping tree, cn=config
    changetype: add
    objectclass: top
    objectclass: nsDS5Replica
    cn: replica
    nsDS5ReplicaRoot: $SUFFIX
    nsDS5ReplicaID: $REPLICA_ID
    nsDS5ReplicaBindDN: cn=Replication Manager, cn=replication, cn=config
    nsDS5Flags: 1
    nsDS5ReplicaType: 3
    nsDS5ReplicaPurgeDelay: 604800
    

    $SUFFIX - directory suffix which is being replicated $REPLICA_ID - unique integer value for each master, e.g. 1 for primary, 2 for secondary, etc. NOTES: "nsDS5ReplicaType: 3" configures this DSA as a replica master, while "nsDS5Flags: 1" regulates creation of changelog db.

  • replication manager password:

    dn: cn=Replication Manager, cn=replication, cn=config
    changetype: modify
    add: userPassword
    userpassword: $PASSWORD
    

    $PASSWORD - password which has to be used by the other masters in topology

  • replication agreement:

    dn: cn=$REP_AGREEMENT_NAME, cn=replica, cn=$SUFFIX, cn=mapping tree, cn=config
    changetype: add
    objectclass: top
    objectclass: nsDS5ReplicationAgreement
    cn: $REP_AGREEMENT_NAME
    description: $DESCRIPTION
    nsDS5ReplicaRoot: $SUFFIX
    nsDS5ReplicaHost: $DESTINATION
    nsDS5ReplicaPort: 389
    nsDS5ReplicaBindDN: cn=Replication Manager, cn=replication, cn=config
    nsDS5ReplicaCredentials: $PASSWORD
    nsDS5ReplicaBindMethod: SIMPLE
    

    $REP_AGREEMENT_NAME - short name to distinguish this agreement from other agreements $DESCRIPTION - brief description of the agreement $SUFFIX - directory suffix being replicated $DESTINATION - fully qualified domain name of the destination machine that recieves replication data $PASSWORD - password set for the replication manager on the destination machine

  • initialising the secondary master:

    dn: cn=$REP_AGREEMENT_NAME, cn=replica, cn=$SUFFIX, cn=mapping tree, cn=config
    changetype: modify
    replace: nsDS5BeginReplicaRefresh
    nsDS5BeginReplicaRefresh: start
    

    $REP_AGREEMENT_NAME - short name to distinguish this agreement from other agreements $SUFFIX - directory suffix being replicated

петак нов 24, 2006

Ponovo radi bioskop...

Skoro godinu dana kasnije, nakon prezivljenih turbulencija u Sunu, vracamo se prvobitnoj ideju. Zajednica je konacno pocela da funkcionise, za pocetak kroz mailing listu: serbian-open-solaris-user-group@googlegroups.com Prezentacija ce se pojaviti uskoro, cim skucimo server. Nadam se da taj proces nece potrajati 11 meseci :)

понедељак јан 30, 2006

OpenSolaris User Community of Serbia

Reseni da (Open)Solaris izvedemo iz Tamnog vilajeta i dovedemo "medju narod", pokrenut je projekat OpenSolaris zajednice u Srbiji. Cilj nije samo stvaranje grupe korisnika vec sirenje korisnicke baze i stvaranje zajednice kako radi razvoja i poboljsanja samog sistema, tako i zbog njegove popularizacije. Za pocetak se moze ocekivati sajt sa tehnickim tekstovima, a kako zajednica bude rasla tako ce se radjati i novi projekti.

петак нов 18, 2005

Ko ga uzme kajace se, ko ga ne uzme kajace se jos vise

Hello, World! Kako do sada nisam mogao da nadjem razlog postojanja vecine blogova na Mrezi, resio sam da pokrenem svoj u nadi da ce vremenom poprimiti neki smisao. Motivacija proistice iz cinjenice da bivsa Jugoslavija, tj. konkretno Srbija, pati od hronicne neobavestenosti tehnologija zasnovanih na Solaris Operating Environment resenjima, pa bih iz tog razloga zeleo da doprinesem popularizaciji i stvaranju zajednice oko Sun Microsystemsa i na tim prostorima.
About

Publishing quirks of Sun software popped up during integration.

Search

Categories
Archives
« април 2014
понутосречетпетсубнед
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today