Solaris basics: configuring the DHCP client Comments Off on Solaris basics: configuring the DHCP client

Having covered how to manually configure ethernet interfaces in Solaris, I’ll now go over configuring the DHCP client. Solaris comes bundled with both a DHCP client and server, but here we just want to configure the client to go out and configure a Solaris ethernet interface.

Instead of a hostname.<interface> file, you need to create two empty files – dhcp.<interface> and hostname.<interface>, in the /etc/directory

bash-3.2$ touch /etc/dhcp.e1000g0
bash-3.2$ touch /etc/hostname.e1000g0

Reboot for the changes to take effect.

NOTE: you can have either DHCP or a static IP address – so double check which files are in place under /etc and what their contents are.

DHCP can be checked with the following commands:

bash-3.2$ /usr/sbin/ifconfig e1000g0 dhcp status

And you can release the DHCP lease with:

bash-3.2$ /usr/sbin/ifconfig e1000g0 dhcp release

DHCP from within VMWare will allocate a default router and DNS settings automatically to your Solaris VM. To enable this to work properly, both /etc/defaultrouter and /etc/resolv.conf must be present, but empty.

If these files already exist, just delete them:

bash-3.2$ rm /etc/defaultrouter
bash-3.2$ rm /etc/resolv.conf

Then recreate them as empty files with the touch command:

bash-3.2$ touch /etc/defaultrouter
bash-3.2$ touch /etc/resolv.conf

Now reboot and note the new settings take effect.

Solaris basics: configuring ethernet interfaces Comments Off on Solaris basics: configuring ethernet interfaces

Recently I’ve had several clients who’ve just started with Solaris, and who have had roughly similar questions. So I thought I’d put up a few “How To” posts covering some Solaris basics.

Each LAN interface in Solaris has a configuration file in /etc which is named after the interface name and it’s instance.

So, let’s assume that you have two e1000g interfaces configured – you’d have two configuration files:

/etc/hostname.e1000g0
/etc/hostname.e1000g1

These files will just contain a hostname, which maps to an entry in /etc/hosts.

An example from my OpenSolaris development workstation:

bash-3.2$ cat /etc/hostname.e1000g0 
grond 

And this is /etc/hosts:

# Internet host table 
# 
::1 grond grond.local localhost loghost 
127.0.0.1 localhost 
192.168.13.100	grond grond.local loghost 

When Solaris boots, all it does to configure a LAN interface is look for hostname.* files in /etc. It then looks up the hostname in /etc/hosts to find out the IP address, then configures the interface.

So if you need to change the IP address of a LAN interface in Solaris, all you need to do is edit the hostname entry in /etc/hosts and reboot. For example, to change grond’s e1000g0 IP address to a different subnet, /etc/hosts would be modified to:

# Internet host table 
# 
::1 grond grond.local localhost loghost 
127.0.0.1 localhost 
192.168.125.100	grond grond.local loghost 

Then reboot the host for the changes to take effect.

Solaris kernel tuning when upgrading to Solaris 10 Comments Off on Solaris kernel tuning when upgrading to Solaris 10

When migrating to Solaris 10, most people focus on the more obvious changes, such as using SMF to manage services, and ZFS for the filesystems. Something that seems to catch lots by surprise is what happened to kernel turnables in Solaris 10.

In Solaris, the kernel is largely self-tuning, with each new major release and kernel patch building on this. There’s not really that much to tweak, and for most of the time, you can just leave Solaris to get on with it.

There are always edge cases, though. Oracle is a classic one, and if you’re doing HPC, big compute jobs, or lots of I/O intensive work, you’ll want to start tweaking.

In previous releases of Solaris, this involved digging out the correct syntax from the Solaris documentation, working out what the values should be, then editing /etc/system, followed by a reboot.

Oracle DBAs in particular will now be distressed to note that Solaris 10 happily ignores the settings in /etc/system. If you’re lucky, you’ll see some complaints about deprecated settings in /var/adm/messages.

Lots of the defaults have now been changed in Solaris 10, and they’re a lot more sensible – you shouldn’t really need to play with System V IPC tunables like semaphores and message queues.

The Solaris 10 Tunable Parameters Reference Manual can be found at http://download.oracle.com/docs/cd/E19253-01/817-0404/

Things have changed a bit for Oracle databases as well, which is the most common case for kernel tuning most people will encounter. Solaris Resource Controls – aka projects – are now used to set things up for Oracle.

Setting up a project for Oracle, and then defining the kernel settings, is pretty straightforward:

• Setup a new project for the Oracle user:
  

  projadd user.oracle

• Modify the project to increase the number of semaphores:
  

  projmod -s -K “process.max-sem-nsems=VALUE” ‘user.oracle’

  Where VALUE should be the total number of Oracle processes, + 10. Chris Gerhard has an excellent blog entry here that discusses the pros and cons of fiddling with the number of semaphores.

• Modify the project to set the maximum shared memory segment size:
  

  projmod -s -K “project.max-shm-memory=(privileged,VALUE,deny)” ‘user.oracle’

  This corresponds to the old shmsys:shminfo_shmmax kernel tunable in /etc/system.

Once you’ve done that, you’re all set. The old semsys:seminfo_semmns tunable is now deprecated, and you should find that the resource controls that replaced the old tunables semsys:seminfo_semopm and shmsys:msginfo_msgmni have high enough defaults that you won’t need to tweak them.

There are still lots of Solaris 8 and Solaris 9 machines out there, that are only just coming to the end of their service life. Although Solaris 10 has been out for a while, and we’re looking at Solaris 11 being released soon, many clients are still looking to tackle the challenges that a Solaris 10 migration brings.

Capturing core files in Red Hat Enterprise Linux 1 comment

Capturing core files in Solaris is pretty straightforward – even more so if you’ve used JASS to secure the system. By default JASS will give you a nice /etc/coreadm.conf file:

COREADM_GLOB_PATTERN=/var/core/core_%n_%f_%u_%g_%t_%p
COREADM_GLOB_CONTENT=default
COREADM_INIT_PATTERN=core
COREADM_INIT_CONTENT=default
COREADM_GLOB_ENABLED=yes
COREADM_PROC_ENABLED=no
COREADM_GLOB_SETID_ENABLED=yes
COREADM_PROC_SETID_ENABLED=no
COREADM_GLOB_LOG_ENABLED=yes

This ensures that we keep all our core files in a sensible place, and that they have enough information in the filename to identify where they came from.

With some visualisation applications required Linux – more specifically Red Hat Enterprise Linux (RHEL), you’ll find the handy coreadm tool missing. Core file management is instead configured in the kernel configuration file, /etc/sysctl.conf

We’ve got three main challenges in RHEL:

1. enable core dumps from setuid processes
2. remove file size limits for core dumps
3. stick them all in a sensible place, and give the core files sensible names

To accomplish all of this, we need to add the following lines into /etc/sysctl.conf:

fs.suid_dumpable = 2
kernel.core_pattern = /var/corecore_%h_%e_%u_%g_%t_%p

And then to make sure we aren’t imposing limits on our core files, we add the following to /etc/sysconfig/init:

DAEMON_COREFILE_LIMIT='unlimited'	# don't limit our core file sizes

Luckily there’s just a couple of differences between Solaris and Linux when it comes to naming our core files:

Once you’ve updated /etc/sysctl.conf we can just refresh our settings by running sysctl:

[root@altix ~]# /sbin/sysctl -p
< list of kernel tunables >
fs.suid_dumpable = 2
kernel.core_pattern = /var/core/core_%h_%e_%u_%g_%t_%p
< list of kernel tunables >

Empty config file: ‘/var/ldap/ldap_client_file’ 1 comment

It’s an annoying and recurring problem – your previously configured and well behaved Solaris machine has now dropped off the network, and no-one can log in. Going in via the console shows that all LDAP lookups fail, and that’s why no-one can log in.

/var/adm/messages is filled with cheery messages like this:

ldap_cachemgr[173]: [ID 293258 daemon.error] libsldap: Status: 0 \
 Mesg: Empty config file: '/var/ldap/ldap_client_file'

You’ll also find the LDAP client SMF service has gone into maintenance mode:

bash-3.00$ svcs ldap/client
STATE          STIME    FMRI
maintenance    17:17:42 svc:/network/ldap/client:default

So what happened? The Solaris ldap_cachemgr process regularly talks to your LDAP servers, and at a pre-defined interval (usually 12 hours) it refreshes the client config. This has a number of benefits, not least of which is that you can make one change in the LDAP directory, and the have your clients all update themselves automatically.

This is great for putting a new LDAP server into play, or for doing a server migration.

The problem arises when /var, where the two LDAP configuration files are stored, is full. Unfortunately ldap_cachemgr doesn’t bother to check that it can save the new config – so it tries to replace the two existing config files, fails, and ends up writing zero byte files in their place.

Luckily the fix is a simple one – simply copy ldap_client_cred and ldap_client_file from another working server into /var/ldap, and then restart the ldap_cachemgr.

bash-3.00$ svcadm clear ldap/client
bash-3.00$ svcs ldap/client
STATE          STIME    FMRI
online         17:17:42 svc:/network/ldap/client:default

The workaround is to make sure that the /var partition never fills up. If it’s 100% full it’s bad for a number of reasons, and you need to put processes in place to trigger alerts to stop this happening.

The bug in ldap_cachemgr is being tracked with SunSolve Bug ID 6495683 – “LDAP client files & cred files are deleted when /var is full”

The ldap_cachemgr can also be queried to find out who it’s bound to – and also when it will next be refreshing the LDAP client configuration. Pass it the -g option:

bash-3.00$ /usr/lib/ldap/ldap_cachemgr -g

cachemgr configuration:
server debug level          0
server log file "/var/ldap/cachemgr.log"
number of calls to ldapcachemgr         30

cachemgr cache data statistics:
Configuration refresh information: 
  Previous refresh time: 2009/06/03 05:17:42
  Next refresh time:     2009/06/03 17:17:42
Server information: 
  Previous refresh time: 2009/06/03 09:57:42
  Next refresh time:     2009/06/03 11:17:42
  server: 192.168.13.101, status: UP
Cache data information: 
  Maximum cache entries:          256
  Number of cache entries:          0