Monday Jan 11, 2010

More Sun Ray on OpenSolaris build 130

As I have previously mentioned I have Sun Ray "working" on OpenSolaris build 130 at home. There are some minor tweaks required to get things working close to perfectly.

If you are doing this you are already running OpenSolaris build 130 and Sun Ray which is completely unsupported. These changes are also completely unsupported. There was not warranty but if there was one you will void it.

First take a back up. Since you are running OpenSolaris and therefore have ZFS take snapshot of the file system that contains /opt/SUNWut and also use beadm to create a snapshot of the boot environment.

Now to get to a point where you can login on a Sun Ray DTU you need to do this:

ln -s /usr/lib/xorg/libXfont.so.1 /opt/SUNWut/lib
ln -s /usr/lib/xorg/libfontenc.so.1 /opt/SUNWut/lib
rm /usr/lib/xorg/modules/extensions/GL
ln -s ../../../../../var/run/opengl/server \\
/usr/lib/xorg/modules/extensions/GL
mkdir /etc/opt/SUNWut/X11
echo "catalogue:/etc/X11/fontpath.d" > /etc/opt/SUNWut/X11/fontpath
usermod -d /var/lib/gdm gdm

However the utwho command won't work and if you want to use utaction as root you need to follow the instructions in my last post.

Now utwho is extremely useful and for me a requirement as it is used by my access hours script so I wanted to get that working. As with the issues with utaction the first problem is that the script that sets this up expects to run as root but now everything is running as the user "gdm". Again the solution is RBAC.


Follow the instructions from my last post to set up a GDM profile and make the user gdm use it. Then add these lines to /etc/security/exec_attr:

GDM:solaris:cmd:::/etc/opt/SUNWut/gdm/SunRayInit/Default:uid=0
GDM:solaris:cmd:::/etc/opt/SUNWut/gdm/SunRayPostSession/Default:uid=0

and then edit the two file listed above to add in the bold lines below. The example is /etc/opt/SUNWut/gdm/SunRayInit/Default:

#!/bin/ksh
# iterate over the helpers directory
#
# ident "@(#)InitDefault.sh     1.5 09/07/31 SMI"
#
# Copyright 2009 Sun Microsystems, Inc.  All rights reserved.
# Use is subject to license terms.
#

PATH=/usr/bin/X11:/usr/X11R6/bin:/opt/X11R6/bin:/usr/bin:$PATH

if [[ "$_" != "/usr/bin/pfexec" ]] && [[ -x /usr/bin/pfexec ]]

then

        exec /usr/bin/pfexec $0 $@

fi


for i in /etc/opt/SUNWut/gdm/SunRayInit/helpers/\*
do
        if [ -x $i ]; then
            . $i
        fi
done

exit 0

Finally, and quite whether this is required I'm not sure, but the reset-dpy script will not work properly either so make these changes to fix it:


\*\*\* /opt/SUNWut/.zfs/snapshot/month_2009-12-01-01:02/lib/xmgr/gdm/reset-dpy     Tue Oct 20 01:32:31 2009
--- ./reset-dpy Mon Jan 11 13:59:30 2010
\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
\*\*\* 65,70 \*\*\*\*
--- 65,71 ----
        dpys=`gdmdynamic -l | /bin/sed -e 's/:\\([\^,]\*\\),[\^;]\*/\\1/g' -e 's/;/ /g' `
        for dpy in $dpys
        do
+         dpy=${dpy#:}
            if [[ $dpy -ge $MINDISP && $dpy -le $MAXDISP ]]; then
            rm "$PRESESSION_DIR/:$dpy"
              rm "$POSTSESSION_DIR/:$dpy"
root@pearson:/etc/opt/SUNWut/xmgr#       

Now all will work:

: pearson FSS 2 $; utwho -c 
 12.0 Payflex.500a094f00130100         user2      192.168.1.228   P8.00144f57a46f
: pearson FSS 3 $; utwho
 12 Payflex.500a094f00130100             user2     
 14 Payflex.500a094d00130100             user1     
 18 Payflex.500a094c00130100             user3     
 19 Payflex.500a094e00130100             user4     
: pearson FSS 4 $; 

However you have voided your warranty!

Update: 12/1/2010 These problems should be fixed in build 132 so the workarounds should not be needed then.

Thursday Aug 27, 2009

Starting remote X applications

Someone has posted a script to start a remote xterm on BigAdmin which exposes a number of issues I thought it would be better if google stood some chance of finding a better answer or at least an answer that does not rely on inherently insecure settings.

Remote X applications should be started using ssh -X so that the X traffic is encrypted and if you add -C compressed which can be a significant performance boost. So a script to do this could be handy although to be honest knowing the ssh options or having them set as the default in your .ssh/config is just as easy:

: exdev.eu FSS 31 $; egrep '\^(Compress|ForwardX)' ~/.ssh/config
ForwardX11 yes
Compression yes
: exdev.eu FSS 32 $; ssh -f pearson /usr/X11/bin/xterm         
: exdev.eu FSS 33 $; 

or more usefully to start graphical tools:

: exdev.eu FSS 33 $; ssh -f pearson pfexec /usr/sadm/admin/bin/dhcpmgr
: exdev.eu FSS 34 $; 

However if you really want a script to do it here is one that will and no need to mess with your .ssh/config

#!/bin/ksh
REMOTE_PATH=${REMOTE_PATH:-${PATH}}
APP=${0##\*/}
if (( $# < 1 )) 
then
        print "USAGE: ${APP} host [args]" >&2
        exit 1
fi
host=$1
shift
exec /usr/bin/ssh -o ClearAllForwardings=yes -C -Xfn $host \\
        PATH=${REMOTE_PATH} pfexec ${APP#r} $@

If you save this into a file called “rxterm” then running “rxterm remotehost” will start an xterm on the system remotehost assuming you can ssh to that system.

More entertainingly you can save it as “rdhcpmgr” and it will start the dhcpmgr program on a remote system and securely display it on your current display (assuming your PATH includes /usr/sadm/admin/bin and your profile allows you access to that application). You can use it to start any application by simple naming it after the application in question with a preceding “r”.

Sunday Apr 05, 2009

Recovering our Windows PC

I had reason to discover if my solution for backing up the windows PC worked. Apparently the PC had not been working properly for a while but no one had mentioned that to me. The symptoms were:

  1. No menu bar at the bottom of the screen. It was almost like the screen was the wrong size but how it was changed is/was a mystery.

  2. It was claiming it needed to revalidate itself as the hardware had changed, which it catagorically had not and I had 2 days to sort it out. Apparenty this message had been around for a few days (weeks?) but was ignored.

Now I'm sure I could have had endless fun reading forums to find out how to fix these things but it was Saturday night nd I was going cycling in the morning. So time to boot solaris and restore the back up. First I took a back up of what was on the disk, just in case I get a desire to relive the issue. I just needed one script to restore it over ssh. The script is:

: pearson FSS 14 $; cat /usr/local/sbin/xp_restore 
#!/bin/ksh 

exec dd of=/dev/rdsk/c0d0p1 bs=1k
: pearson FSS 15 $; 

and the command was:

$ ssh pc pfexec /usr/local/sbin/xp_restore < backup.dd

having chosen the desired snapshot. Obviously the command was added to /etc/security/exec_attr. Then just leave that running over night. In the morning the system booted up just fine, complained about the virus definitions being out of date and various things needing updates but all working. Alas doing this before I went cycling made me late enough to miss the peleton, if it was there.

Thursday Dec 15, 2005

Letting users create ZFS file systems

Darren has just posted his fast bringover script that solves some of my desire to be able to have a file system per workspace. I'm not commenting on the script since it manages to trip one of my shell script peeves that of calling a program and then calling exit $?. What is wrong with exec? I'll keep taking the tablets.

However it does not solve my wanting to be able to let users be able to create their own ZFS file systems below a file system that they own.

Like I said in the email this can mostly be done via an RBAC script, well here it is:

#!/bin/ksh -p

PATH=/usr/bin:/usr/sbin

if [ "$_" != "/usr/bin/pfexec" -a -x /usr/bin/pfexec ]; then
        exec /usr/bin/pfexec $0 $@
fi

function get_owner
{
	echo $(ls -dln ${PARENT} | nawk '{ print $3 }')
}

function create_file_system
{
	typeset mpt name

	zfs list -H -t filesystem -o mountpoint,name,quota | \\
		 while read mpt name quota
	do
		if [[ $mpt == $PARENT ]]
		then
			zfs create ${DIR#/} && chown $uid $DIR && \\
				zfs set quota=${quota} ${DIR#/}
			exit $?
		fi
	done
	echo no zfs file system $PARENT >&2
	exit 1
}

function check_quota
{
	typeset -i count
	typeset mpt name
	count=0

	zfs list -H -t filesystem -o mountpoint,name | while read mpt name
	do
		if [[ $(get_owner $name) == $uid ]]
		then
			let count=count+1
		fi
	done
	echo $count
}

MAX_FILE_SYSTEMS_PER_USER=10

test -f /etc/default/zfs_user_create && . /etc/default/zfs_user_create

if [[ $# -ne 1 ]]
then
	echo "Usage: $1 filesystem" >&2
	exit 1
fi

DIR=$1
PARENT=${1%/\*}

if ! [[ -d $PARENT ]]
then
	echo "$0: Failed to make directory \\"$1\\"; No such file or directory" >&2
	exit 1
fi

uid=$(id | sed -e s/uid=// -e 's/(.\*//')
owner=$(get_owner $1)

if [[ $uid != $owner ]]
then
	echo "$0: $1 not owner" >&2
	exit 1
fi

if [[ $(check_quota) -gt ${MAX_FILE_SYSTEMS_PER_USER} ]]
then
	echo "too many file systems"
	exit 1
fi

create_file_system

It has a hack in it to limit the number of file systems that a user can create just to stop them being silly. Then you just need the line in /etc/security/exec_attr:


All:suser:cmd:::/usr/local/share/sh/zfs_create:euid=0

Now any user can create a file system under a file system they already own. The file systems don't share a single quota which would be nice but for my purposes this will do.


Next trick to let them destroy them and take snapshots of them. The snapshots being the real reason I want all of this.

Tags:

Saturday Jul 02, 2005

A new root shell.

Fed up with the bourne shell for root? All the power of root but with a proper shell, not csh, a proper shell! You can add a role with the korn shell or any other shell and then assign that role to the users you wish to be able to access it. They still have to type the password of the role but they get a sensible shell when they get it right, plus others don't even get the option.

Here is how. For the a korn shell “root” account:

# roleadd -d /root -P "Primary Administrator" -s /usr/bin/pfksh kroot
# usermod -R root,kroot me
# passwd kroot
New Password:
Re-enter new Password:
passwd: password successfully changed for kroot
#

Now I have a role, kroot, to which only I can su(1M) and it has a decent shell. I can still use the root role if I want pain and I have not changed root's shell which is probably a good thing. Make sure /root already exists, it did for me as it is root's home directory already.


Tags:

About

This is the old blog of Chris Gerhard. It has mostly moved to http://chrisgerhard.wordpress.com

Search

Archives
« April 2014
MonTueWedThuFriSatSun
 
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