When doing system administration it is often more convenient to connect to a server through some sort of remote connection setup rather than having to sit at a console in a datacenter. The comfort of one’s office (or living-room) is often far superior in terms of noise and temperature than the environs of the datacenter itself.
When setting up the RHEL5 server this week here at VSU, I was forced to use the Sun iLOM connection to do the initial install of the server. While I generally use command-line only tools, the ease of use one gains from the GUI tools can often make some tasks much simpler. Towards this end I decided to setup the server and my client to allow XDMCP sessions so that I could have full access to the GUI when necessary.
On the server there are a couple of things that you need to configure in order to make this workFirew:
- Firewall ports
- GDM configuration options
On the client you will need to configure the OS X firewall, as well as use the correct Xephyr connection syntax.
Continue reading
One of the standard methods of configuring Mac OS X in the enterprise has become known as the magic triangle or golden triangle. This is generally described as a setup involving Active Directory (AD) for authentication of the clients and services and Open Directory (OD) for managing the client preferences. The triangle comes from the fact that you have the Mac clients talking to AD, the clients also talking to OD, and the Mac server talking to AD. (Apple officially calls this the magic triangle setup in the Snow Leopard Server Open Directory Administration documentation.)
One of the issues I ran into was granting a non-admin in AD the ability to perform administrative functions on the clients bound to AD. The way this is handled with the Windows clients is for the particular AD user to be a member of a group that grants local administrator privileges.
Unfortunately there is no simple equivalent on the OD side of the equation to allow this for the technicians working on the Mac OS X clients. If you add an AD user to the system level group Open Directory Administrators using Workgroup Manager (WGM) this has no effect on whether a user is granted local administrator privileges to a connected client machine.
The solution to this involves:
- creating a group in OD to hold the members of AD that should have local administrative privileges,
- adding this OD group to the requisite local workstation groups to mimic the standard administrative privileges, and
- adding the OD group to the sudoers file
Continue reading
At work we currently use version 3.3.3 of the Luminis III platform by SunGard Higher Education. This product handles our mail and portal needs for the time being. While it is definitely not the best web-based mail client in the world I have seen worse.
Recently I had received a notice from a friend that he couldn’t read my signed e-mail in the web-client. After having him forward the message to me as an attachment, I determined that the problem had to do with my digital signature.
I use Apple’s Mail client for OS X 10.5. Currently I also have GPGMail by Stéphane Corthésy installed so that I can seamlessly use my GPG keys to sign and encrypt my e-mail. After sending an unsigned message and finding out that it went through with no problems, I started investigating the options provided by GPGMail.
It turns out that I had checked the option to use OpenPGP/MIME by default. Apparently this creates an message body that the Luminis III web-mail client can’t read. So if you are running into this problem with a web-based client, check to see if your messages are going out as OpenPGP/MIME.
At work I am in charge of running our Macromedia Adobe Contribute Publishing Server.
Since I like to duplicate my work environment on my laptop for local development, I needed to install JBoss 4.0.5.GA. I won’t go into why we are running such an old version, that’s all Adobe’s fault.
Installing JBoss
- Download the JEMS installer for 4.0.5.GA from the JEMS Installer Downloads page at jboss.org.
- Execute the installer:
java -jar jems-installer-1.2.0.GA.jar - If you get asked to allow java to talk through the firewall, choose Allow.
- The default installation location is: /Applications/jboss-4.0.5.GA
It will create the directory if it doesn’t exist already.
- During the install process choose the Advanced install method. This allows you to pick your database environment, as well as making the process of securing the JMX Console and JBoss Web Console much easier.
Starting JBoss
- Open a terminal
- Goto the install location binary directory (I used the default)
/Applications/jboss-4.0.5.GA/bin/ - execute run.sh
./run.sh -b 127.0.0.1 & - You will see the output of the startup process show up in the terminal window.
Stopping JBoss
- Open a terminal
- Goto the install location binary directory
cd /Applications/jboss-4.0.5.GA/bin - Run the shutdown script (don’t forget to authenticate!)
./shutdown.sh –server=localhost:1099 –shutdown -u admin -p password
Notes
- The default port for the HTTP connector is 8080
- The SSL connector is disabled by default
In the application selection process for 10.5, the X11 maintainers elected not to include Xnest.
While most users will probably not need this, since you can export X11 application through a SSH connection, sometimes it is quite handy to have the entire gui session available from a remote server.
I use this when managing some of my Solaris servers. With X11 on 10.4 this was readily available, but after installing 10.5 I found that it had not been included. Initially I just copied the binary from my 10.4 install into the expected location and tried to use it. However, as I expected, the results were not particularly satisfactory, given that the binary was built against a different X11 source tree.
After posting some of my compile issues to the X11-Users mailing list (archives are here), the code maintainer released a patch to the xorg code that fixed the symbol issues that had reared their ugly heads.
For those who are interested in making it work here’s what you need to do:
- Follow the first seven lines under the section Source installation on the XDarwin wiki page
- Change the configure instruction line to be as follows:
./configure --prefix=/usr/X11 --enable-xnest=yes --with-mesa-source=`pwd`/../Mesa-6.5.2 - Continue with the rest of the source instructions as posted in the wiki page
- After copying the new Xquartz binary over, copy the Xnest binary as well:
sudo cp hw/xnest/Xnest /usr/X11/bin/ - Don’t forget the manpage:
sudo cp hw/xnest/Xnest.1 /usr/share/man/man1/
Now you have a nicely patched install of the latest fixes for Xquartz as well as the Xnest binary.
If only compiling Xpehyr was working now…sigh.
Resources:
- Applications supplied with the default X11 install on 10.5