|

Thursday December 23, 2004
Solaris USB FAQ
The IO folks have posted a faq about USB on Solaris. Very usefull.
(2004-12-22 21:30:43.0)
Permalink

Monday December 20, 2004
Using ldapmodify to tune your directory server
The Sun Java Enterprise System Directory Server has a bunch of different things that you can tune, I have mentioned these before, but never gave the actual commands to do the tunings.
One of the rigs that we maintain in my group runs DirectoryMark 1.3, which to be honest is a very poor benchmark, but needs to be run none the less, and as it happens I needed to quickly update a few things in the config today. As an aside, if your benchmarking directory servers, take a look at Slamd, which was recently opensourced by Sun. It contains a much more detailed set of LDAP workloads, and also allows you to create custom workloads.
Anyway, onto the brief tuning. Once your server is up and running you use the ldapmodify(1) command to update the server. The major things that you are going to look at are things such as your search size limit, cache size, db cache size etc. All of these take pretty much the same syntax of
ldapmodify -h Directory server host -p port -D Directory Manager DN -w Directory Manager Password
dn: relevant dn
changetype: modify
replace: attribute
attrbute: value
So in this case, due to a some issues with DirectoryMark I need to change my time limit to unlimited (this is just the easiest work around for the issues we faced with this benchmark, never, ever do this in production unless you trust everything that is using your ldap servers). So the affected setting is nsslapd-timelimit within the config dn. So this gives us a command of the following (the <<EOF to EOF section is for scripting this)
ldapmodify -h ms -p 389 -D cn="Directory Manager" -w yourpassword << EOF
dn: cn=config
changetype: modify
replace: nsslapd-timelimit
nsslapd-timelimit: -1
EOF
and so on, I've included a couple of the other modifications I made below for your perusal. All of these settings are dealt with in detail in the Server Configuration Reference section of the Directory Server documentation.
Turn logging off, this is solely for benchmark purposes. Again you should have some form of logging in a production environment.
ldapmodify -h ms -p 389 -D cn="Directory Manager" -w yourpassword << EOF
dn: cn=config
changetype: modify
replace: nsslapd-accesslog-logging-enabled
nsslapd-accesslog-logging-enabled: off
EOF
Update the cachememsize and so on....
ldapmodify -h ms -p 389 -D cn="Directory Manager" -w yourpassword << EOF
dn: cn=userRoot,cn=ldbm\040database,cn=plugins,cn=config
changetype: modify
replace: nsslapd-cachememsize
nsslapd-cachememsize: 314572800
EOF
And the remaining tunings are left to the reader ;).
(2004-12-20 02:22:18.0)
Permalink

Thursday December 09, 2004
An appserver gotcha and work around
Got stung with this for a while today, so for the benefit of others....
I had just installed an internal development version of the Sun Java System Application Server and restored a SpecJAppServer2002 domain. Within in a domain you have a script startserv (and another stopserv) which are called by the asadmin commmand when you start and stop a domain respectively.
So I've restored the domain, and go to startup my appserver
perf-n# ./asadmin start-domain -u admin spec2002-1
Starting Domain spec2002-1, please wait.
Log redirected to /var/opt/SUNWappserver/domains/spec2002-1/logs/server.log.
/var/opt/SUNWappserver/domains/spec2002-1/bin/startserv: cannot execute
CLI156 Could not start the domain spec2002-1.
But now my confusion starts
perf-n# ls -al /var/opt/SUNWappserver/domains/spec2002-1/bin/startserv
-rwxr----- 1 ecuser nobody 3152 Dec 9 02:01 /var/opt/SUNWappserver/domains/spec2002-1/bin/startserv
Looks pretty executable to me.... and I can start it manually.....
Anyway after a bit of fiddling around I figured out that the problem is that you need to have startserv with permissions of 755, a simple chmod 755 startserv and everything is back in business.
In reality your very unlikely to hit this problem if you go through the normal steps for creating and restoring a domain, but as I said on the off chance that your taking a shortcut like me.
(2004-12-08 19:55:58.0)
Permalink

Wednesday December 08, 2004
cars all belong to [insert vendor here].....
I have avoided making comments about Solaris v's Red Hat Enterprise Server
up to now, as folks such as Alan,
Eric and Colm tend to phrase things in a
much more eloquent way.
But the most recent Sun related article on slashdot entitled
Sun's COO Pretends Linux Belongs To Red Hat just
has to be addressed. The anonymous submitter asserts that Jonathan claimed that Linux
belonged to Red Hat. This is just a blatantly skewed, and downright false, interpretation of what Jonathan said.
Jonathan has stated categorically on his blog that Red
Hat is not Linux, Red Hat is a distro, and Red Hat is a competitor for Sun. Nothing more. Red Hat is not Linux, Red Hat is however the
defacto Linux OS in the datacenter, hence it is a competitor for Solaris. And what do you do with competitors?
You compete. You compete on price (free binary right
to use license), you compete on performance, you
compete on features and most importantly you compete by having the most
innovative features (DTrace,
ZFS, Zones,
Process Rights Management,
FireEngine,
Predictive Self Healing,
Linux Compatibility [Janus] and
Event Ports to name but a few) ever in the OS world,
all supported on multiple architectures (sparc,
amd64, x86).
Thankfully a lot of folks reading slashdot pointed out how flawed the submitters analysis was, just set
+5 as your moderation point
to filter out the fluff. The comment could be viewed as analogous to saying Skoda make cars,
Ferrari said they feel Skoda are one of their
competitors and are going to compete against them, therefore Ferrari have said all cars are owned/made by Skoda. A flawed argument one thinks.
Oh, on a different note, Solaris Express 11/04 is out, its the
same build that is running on my laptop as I write this, download it and try out all of the new features in Solaris 10.
(2004-12-07 20:03:57.0)
Permalink
|