Friday Jul 04, 2008

A Simple VNC Server and GDM Configuration Example for OpenSolaris 2008.05

My requirement was to be able to connect my VNC client to a system running OpenSolaris 2008.05 and to be able to login as root. I have now done this successfully on a  system running the original OpenSolaris 2008.05 binary distribution and on a system running OpenSolaris 2008.05 after I ran a full image update to snv_91.

Update September 19th 2008: This procedure does not work if you have updated the image to snv_97 but does work if you update the image to snv_98. The upgrade from snv_97 to snv_98 wiped out the entries I had made in /etc/X11/gdm/custom.conf so I had to make those again. I have added an extra step at the end, based on Chris Drake's comments, to make the VNS server session persist if you exit the client.

1. Check that the VNC Server is Installed

This should be present as it is part of the 2008.05 binary distribution, but I checked anyway.

# pkg info SUNWxvnc
          Name: SUNWxvnc
       Summary: X11/VNC server
         State: Installed
     Authority: (preferred)
       Version: 4.1.2
 Build Release: 5.11
        Branch: 0.91
Packaging Date: Fri Jun 13 17:49:25 2008
          Size: 6.3 MB
          FMRI: pkg:/SUNWxvnc@4.1.2,5.11-0.91:20080613T174925Z

2. Add this line to /etc/services

vnc-server      5900/tcp                        # Xvnc

3. Edit /etc/X11/gdm/custom.conf as below


4. Enable the Services

# svcadm enable xvnc-inetd
# svcs xvnc-inetd
STATE          STIME    FMRI
online         16:22:30 svc:/application/x11/xvnc-inetd:default
# svcadm enable gdm
# svcs gdm
STATE          STIME    FMRI
online         14:43:13 svc:/application/graphical-login/gdm:default

5. Connect to the Display with a VNC Client

You should now be able to connect to <hostname>:5900 and you should see the gdm login screen.

If you cannot connect, try stopping & starting the services:

# svcadm disable xvnc-inetd gdm
# svcadm enable xvnc-inetd gdm

6. Making the Session Persist

This may or may not be desirable for you, but if you want the VNC session to persist if you exit the VNC client then do the following:

# svccfg -s xvnc-inetd

svc:/application/x11/xvnc-inetd> editprop

This take you into a vi session. Look for the line...

#setprop inetd/wait = boolean: false

Copy the line, uncomment it and set it to true. Save the file, exit svccfg and run the command...

# svcadm refresh xvnc-inetd

Connect again with you VNC client. Now, when you exit/kill the VNC client, the session on the server will persist and you will be able to connect to it again.

You may now want to add an extra level of security to enable password protection on your VNC server. That is something that I have been unable to make work...and from searching around, it seems that others have a similar problem.

References: 1, 2

Tuesday May 27, 2008

Making SAMBA Go Faster.....

I do a lot of work with the CIFS server that we now provide as part of OpenSolaris, but I also still do work with SAMBA as well.

I have been experimenting with a workload where I am accessing 100 files from a Windows Server 2003 CIFS client (Sun Fire V40z). The server is a Sun Fire X4500 running SAMBA. I am doing sequential I/O with a  workload generating tool, and at any time 75 files are open for read and 25 open for write. There are 1million files in the file system comprising 4 TB of data.

I was not seeing great scalability or performance, then some research by a colleague (supported by some folk at led me to try enabling Async IO (AIO) on the SAMBA server. This is a standard feature of SAMBA, and has been available in Sun's SAMBA server build since Solaris 10 8/07. From what I have been told , AIO specifically helps the case of client workload scaling w/ threads Vs scaling with many connections; the workload generating tool I am using (vdbench) scales with threads.

To enable AIO add these lines to the global part of your smb.conf :

aio read size = 1
aio write size =1

Then restart SAMBA.

This parameter is defined in bytes. This setting means that any I/O over 1 byte will be handled asynchronously by smbd. There may be reasons for this to be a bigger value in some cases, I don't know.

Without AIO, my previous best result was 42 MB/sec reads and 14 MB/sec writes; with AIO the client could read at 64.4 MB/sec reads and write a 22.1 MB/sec. CPU utilization on the X4500 running SAMBA went up from 15% to 50%.

Your mileage will vary depending on your workload and application, but that is quite a nice boost for just adding two lines to a configuration file :-)

Note: This work was done running the Solaris Express Community Edition snv_89 X86 (aka Nevada) on the Sun Fire X4500. The underlying file system was a ZFS file system provisioned from a RAID-Z storage pool configured as described here. I was reading/writing 8KB blocks.

Friday Apr 18, 2008

On Losing My Father.....

It is rare that I make a personal entry in this blog, but this lunchtime I took a walk through the Botanical Gardens close to my home and I was moved to write something about the recent death of my father, who had shared a love of nature and gardening with my late mother.

The relationship with one's parents can be difficult and since his death I have tried not to remake history, but I have often thought what would I say about my father if asked and here it is...

Dennis Victor Thomas: Born Feb 1st 1922, Died February 24th 2008.

At various times in his life he was a soldier, a lorry driver, a farmer, a welder, a carpenter and a builder...and for most of his life he was a father.

A veteran of World War II, he was a driver in the 8th Army through North Africa and Italy. He was present at the Battle of Monte Casino, something he only mentioned once, as is the way of his generation.

He was a father to four sons: Paul, Christopher, Michael and Timothy (me).

My parents were intensely private people so I shall share no more of their lives other than to say that he died almost four years to the day after my mother, his wife of 57 years.

Of my father: I shall just say that he was a quiet and gentle man with a good kind heart...and he did his best. Uncomfortable with his emotions, he was a silent provider for his family. I only found out of his pride in me from others. He showed his love for his grandson, our 8 year old, by saving his meager pension and quietly delighting in giving him the money when we visited him.

A lovely poem was read at the end of my mother's funeral service. I was surprised to find a cutting of it in my fathers wallet after he died, and it was read at the end of his funeral also. It is a famous inspirational poem attributed to Mary Frye.

Do Not Stand At My Grave And Weep

Do not stand at my grave and weep
I am not there; I do not sleep.
I am a thousand winds that blow,
I am the diamond glints on snow,
I am the sun on ripened grain,
I am the gentle autumn rain.
When you awaken in the morning's hush
I am the swift uplifting rush
Of quiet birds in circling flight.
I am the soft starlight at night.
Do not stand at my grave and cry,
I am not there; I did not die.

[I have disabled comments on this entry.]

Friday Apr 11, 2008

OpenSolaris as a StorageOS - The Week That Everything Worked First Time

This has been an extraordinary week...everything I have tried to do has worked first time.

To summarise this weeks activities, I have set-up and then blogged on:

Configuring the OpenSolaris CIFS Server in Workgroup Mode
Configuring the OpenSolaris CIFS Server in Domain Mode
Solaris CIFS Windows SID Mapping - A First Look
Configuring the OpenSolaris Virus Scanning Services for ZFS Accessed via CIFS Clients

All in all..a very good week :-) 

Configuring the OpenSolaris Virus Scanning Services for ZFS Accessed via CIFS and NFSv4 Clients

OpenSolaris includes features that enable virus scanning of files accessed by CIFS and NFSv4 clients. You can read about the project on the OpenSolaris Project: VSCAN Service Home Page. The scanning model is similar to that discussed in this article in that files are sent (using the ICAP protocol) to external servers running anti virus software to be scanned...a common model for NAS appliances.

Having set up the OpenSolaris CIFS server as described here, I wanted to try out these services. Part of my job at Sun is to certify anti virus software with our NAS products, so I am experienced in this kind of testing.

As before, I am working on a Sun Fire X4500 with Solaris Nevada build 86 installed....

root@isv-x4500b # uname -a
SunOS isv-x4500b 5.11 snv_86 i86pc i386 i86pc

I have mostly presented the commands I have used as is..but I have occasionally had to edit fields.

I installed a copy of the Symantec Scan Engine Version 5.1 on a Windows server (hostname: scanengine) in my lab to provide the necessary scanning services. The Symantec Scan Engine has an ICAP protocol interface as standard, so enabling the OpenSolaris VSCAN service to communicate with it.

I configured the Symantec Scan Engine in "Scan Only" mode which means that it will notify the VSCAN service if a file is infected or will not attempt to repair infected files (i.e. if won't remove the virus). The response of the VSCAN service to being told that a file is infected is to set attributes on the file so that access is denied i.e. the file is quarantined.

The VSCAN services are managed with the vscanadm command. The vscan service daemon, vscand, interacts with the scan engine to have the file scanned; sending the file contents to the scan engine via the ICAP protocol.

I wanted to enable virus scanning on a CIFS share called cifs2 which is a share off the ZFS file system tank/cifs2. The procedure was as follows:

1. Enable VSCAN Services

root@isv-x4500b # svcadm enable vscan
root@isv-x4500b # svcs vscan
STATE          STIME    FMRI
online          7:38:08 svc:/system/filesystem/vscan:icap

2. Enable Virus Scanning on the ZFS File System

root@isv-x4500b # zfs set vscan=on tank/cifs2

NOTE: In the next steps you should substitute the hostname of your server running anti virus software for scanengine.

3. Add a Scan Engine

root@isv-x4500b # vscanadm add-engine scanengine
root@isv-x4500b # vscanadm get-engine scanengine

NOTE: Port 1344 is the default for ICAP, it can be changed. If you changed it you would also need to change the port used by the anti virus software.

4. Optional Step - Set Maximum Size of File To Sent To Be Scanned

It is inefficient to scan very large files. Here we set maximum size of a file to be scanned to 100 MB. If a file 100MB in size, or greater, needs to be scanned you have an option of allowing access or denying access: in either case the file will not be scanned.

root@isv-x4500b # vscanadm set -p max-size=100M
root@isv-x4500b # vscanadm set -p max-size-action=deny
root@isv-x4500b # vscanadm show


5. Optional Step - Modify The List of Types of File to Scan

By default all file types are scanned. Here we remove files ending in "jpg" from the list of files types to be scanned.

root@isv-x4500b # vscanadm set -p types=-jpg,+\*
root@isv-x4500b # vscanadm show


6. Checking That Scanning is Working

You can get files from EICAR to test virus scanners. The files look like viruses to the scanners, but are safe to use.

I mounted up the cifs2 share on a Windows server and created some files and Folders on the share with no issues. I then drag and dropped EICAR files from the Window server's unprotected drive onto the share. When I tried to open an EICAR file on the share, access was denied.


Messages like the one below appeared in the system log.

Apr  9 08:13:09 isv-x4500b vscand: [ID 540744 daemon.warning] quarantine /tank/cifs2/ 11101 - EICAR Test String

Back on the server running OpenSolaris I checked to see if files had actually been scanned as below

root@isv-x4500b # vscanadm stats

File are being scanned and there are no scan errors! 

Lastly, I also looked at the statistics on the Symantec Scan Engine GUI which also confirmed that files were being scanned. Note that the numbers below do not match the output of vscanadm above as the screenshot was taken a a later time.

Symantec Scan Engine

Access is denied to the infected files because the quarantine bit has been set. You can check for the q for quarantine bit as follows...

root@isv-x4500b # ls -/c
----------+  1 2147483649 2147483650      68 Apr  9 08:13

For More Information

OpenSolaris Project: VSCAN Service Home Page

vscanadm and  vscand manual pages.

Thursday Apr 10, 2008

Solaris CIFS Windows SID Mapping - A First Look

This follows directly on from where I set up an OpenSolaris CIFS server in Domain Mode. When I mapped the share I was not asked for a user ID and password as I had been in Workgroup, how are file and folder ownership and permissions handled ?

The Solaris CIFS implementation includes ID Mapping Services. These services let you explicitly map Windows Security IDentifiers to Solaris User IDs and Group IDs if you wish, but if you don't set up explicit mappings then the ID Mapping Service will generate Ephemeral Solaris User IDs and Group IDs for Windows Users. The Solaris CIFS Administrators Guide discusses Identity Mapping strategies.

Permissions on the files and directories created at the end of the previous exersize, when listed from Solaris, look like this...

root@isv-x4500b # pwd
root@isv-x4500b # ls -l
total 10
d---------+  2 2147483649 2147483650       2 Apr  8 05:49 user1
----------+  1 2147483649 2147483650       0 Apr  8 05:57 user1.txt
d---------+  2 2147483650 2147483650       3 Apr  8 05:50 user2
----------+  1 2147483650 2147483650       0 Apr  8 05:51 user2.txt

This looks a bit odd because the OpenSolaris CIFS service uses ZFS ACLs, and they don't show up in the above listing. We can dump the current ID Mappings, as below...

root@isv-x4500b # idmap dump
usid:S-1-5-21-500772251-2770406677-2360070262-1125      ==      uid:2147483650
usid:S-1-5-21-500772251-2770406677-2360070262-1113      ==      uid:2147483649
gsid:S-1-5-21-500772251-2770406677-2360070262-513       ==      gid:2147483650
gsid:S-1-5-21-500772251-2770406677-2360070262-512       ==      gid:2147483651
gsid:S-1-5-11   ==      gid:2147483652
gsid:S-1-5-2    ==      gid:2147483653
gsid:S-1-5-32-544   ==      gid:2147483654

We can see that Windows SIDs have been mapped to Solaris User and Group IDs.  The mappings for the users have been created on the fly (Ephemeral ID Mapping); the Windows Group SID mappings are generated by system level interactions, you can decode those using the list here. We can see that:

Windows Group SID xxxxxx-513 = Domain Users = Solaris GID 2147483650

Windows Group SID xxxxxx-512 = Domain Admins = Solaris GID 2147483651

Windows Group SID xxxxxx-11 = Authenticated Users = Solaris GID 2147483653

Windows Group SID xxxxxx-2 = Network (Users logged in via the Network) = Solaris GID 2147483651

Windows Group SID xxxxxx-544= Administrators  = Solaris GID 2147483654

We now know that the files and directories we created are in the Domain Users group as it was mapped to the Solaris GID of 2147483650.

Sometime soon I am going to dig deeper on all this, this was just a first look. 

For More Information

OpenSolaris Project: CIFS Server Home Page

Open Solaris CIFS Documentation including the Solaris CIFS Administrators Guide & Troubleshooting Information

Also, consider joining the Open Solaris Storage Discuss Forum


Tim Thomas


« July 2016