I recently transferred data from an old G5 running 10.4.6 Server to a G5 XServe. All was running well until I launched the Server Monitor application to check the hardware status of the server. The Server Monitor application reported "waiting for response from server." I finally found out that the hwmond config needed to be modified. Rather than editing the file, I ran the hwmondSetup tool via Terminal.
Log in with root access (normally via sudo on the main admin account), then run this command:
After installing the Java 2Platform Standard Edition (J2SE) 5.0 Release 4 on my OS X server running QLA 3.5, the QLA server would not open, run or even uninstall. I had to do the following to revert it back to Java 1.4.2:
In Terminal, run the following commands:
$ su root
$ cd /
$ cd System/Library/Frameworks/JavaVM.Framework/Versions/
$ sudo rm -rf CurrentJDK
$ sudo ln -s 1.4.2 CurrentJDK
After executing the above mentioned commands you should be able to install QLA.
[kirkmc adds: I haven't tested this, but there's always a risk in removing anything rather than backing it up first. So at the rm -rf command, I'd suggest making a copy of the directory with a different name.]
When ssh'ing into an OS X client as a user whose home directory is mounted on an AFP server, the following errors can occur. First, during the login process:
/usr/X11R6/bin/xauth: error in locking authority file ~/.XAuthority
Second, if one tries to start an X11 application, the following error occurs:
X11 connection rejected because of wrong authentication.
X connection to localhost:10.0 broken (explicit kill or server shutdown).
The problem seems to be that xauth cannot update the .Xauthority file when the ssh session starts up, rendering the user unable to authenticate to the X server connected to their ssh session. A workaround to this problem is to have xauth write the session authnetication cookie info to a file on the local disk, not in the AFP-mounted home directory. One needs to create an /etc/sshrc file to do this.
OS X Server's Weblog/Podcasting Server (based on Blojsom) is pretty darn cool, but it seems like one should be able to do a lot more from the Admin perspective with one's blog. (For example, deleting a blog category that you previously created). Currently, it appears there is no way to do this -- but there is. It is called the Blojsom Administration Console, and Apple disables it by default, but you can enable it for any blog (on a blog-by-blog basis). Here's how...
To turn on (enable) the Blojsom Administration Console, you just need to uncomment a line in a configuration text file, and then restart Blojsom. First navigate into the proper directory (all of the following is in Terminal):
$ cd /Library/Tomcat/blojsom_root/webapps/ROOT/WEB-INF/username
Replace username with the user's short username. Then open flavor.properties (as root) with your favorite Terminal editor:
$ sudo vi flavor.properties
Once you have it open, remove the hash mark (#) from the front of this line:
Here at the school district, I was running into a problem where if several Mac OS X wireless clients logged into the network at once, everything slowed down to a crawl. After researching the problem, it looked like the user's Library and Microsoft User Data folders were causing the problem.
I tried turning on OS X's home folder syncronization, but that didn't work very well, and filled up our older computers fast. The solution I found was to locally cache the user's Library and Microsoft User Data folder. To do this, create a symbolic link from the user's networked 'Library' folder, and point it to a local source -- I used /tmp/UserCache/user/Library, where user is the user's short username. Here is the login script I created to automate the process:
# Create local user caches of important directories
# Written by Steven Eppler 04/04/2006
# Set user variable
# This grabs the user's home directory server
input=`dscl localhost read Search/Users/$user NFSHomeDirectory`
# Or you can hardcode it...
# Check for blank nethomedir - otherwise you will delete
# the root /Library folder!
if [ """$nethomedir""" != "" ]; then
# Create local caching directories
mkdir /tmp/UserCache/$user/Microsoft User Data
# Give everyone rights to them...
chmod -R ugo=rwx /tmp/UserCache
# Create Documents and Desktop folder (sometimes they don't exist)
# Delete old folders or links
rm -rf $nethomedir/Library
rm -rf $nethomedir/Documents/Microsoft User Data
# Create new links
ln -s /tmp/UserCache/$user/Library $nethomedir/Library
ln -s /tmp/UserCache/$user/Microsoft User Data $nethomedir/Documents/Microsoft User Data
Note that this comes from an entry on my blog; future code updates will likely appear there.
But what's even better is one can create an Universal NetBoot Image, too! Simply image the partition, open the .plist file in the image folder, and add the entry ppc to architectures. Now you can activate the image, and even select the supported platform - PowerPC, Intel or both: Universal.
I tested this with an iMac G5 17" and an Intel iMac 17" (the Intel iMac is much faster).
[robg adds: I wish I had more detail to add on this (such as the exact name of "the .plist file"), but I can't test it myself, and the author left no contact info.]
I was encountering a couple of issues with my OS X Server installation.
First, I found that ssh logins to my server, which I access in the dot-local notation (i.e. server-name.local) were suddenly very, very slow. Using ssh without Rendezvous/Bonjour was still normal.
Second, iCal suddenly stopped updating its data to the local WebDAV server, which I also access using the dot-local notation
After some troubleshooting, I tracked down the cause of the problem. The problem was that I had enabled the new OS X Tiger Server 'Stealth Mode for TCP' by checking the box in the Firewall section of Server Admin. Removing the checkmark and saving solved the problem.
I have read on macosxhints.com about many different ways to mount a network share when a user logs in. Many of them require AppleScripts and editing NetInfo databases, neither of which I was particularly comfortable with.
My method, detailed below, has the added benefit of keeping the username and password out of an AppleScript. To my knowledge, this requires Tiger Server and network/mobile accounts.
Mount a share on the machine where you are running the Server Admin tools via the "Connect to Server" dialog box. It is best that this share be of the same type (AFP v. SMB) and on the same server as the shares that you are planning to assign.
Open up Workgroup Manager and connect to the server where your accounts are located.
Select the user(s) you would like to have automatically mount a share. It is not important that they all are mounting the same share, as we will be editing that later.
Click on Preferences at the top of the window. Make sure that Overview is selected (as opposed to details).
Click on Login in the settings area and then make sure that "Login Items" is selected. Click on "Always."
From here click "Add...," and in the new window, select the share that you have mounted on your machine. Again, it is not important that the share here is the one that you would like to mount for each user. Confirm by clicking the add button. This will return you to the Login Items panel.
At this point, you should see a URL with the path to the share that you mounted on your machine. Select that URL and check the box next to "Mount item with user's name and password." Click "Done" at the bottom and confirm by clicking "Save."
Now you should be back in the Overview panel. (If you are doing a group of accounts, select only the ones that you wish to change before the next step.) This time click "Details," and you should see an entry for loginwindow. Select loginwindow and click Edit. This will drop you into a window similar to the PropertyList Editor in Developer Tools. Option-click on the arrow next to "Always" to automagically open all nested entries.
Edit the URL to your heart's content and save. When the user logs in the next time, this URL will be opened with their username and password.
Repeat for all users necessary.
I have not tested this for SMB shares on Windows Servers, but this works well for the shares on the Tiger servers.
Mobile users in an OS X Server / Client setup are prompted at login with a dialog asking if they want to create a portable home directory on the machine they are logging on. They have three buttons to choose from:
Not Now -- just log in to the network account and work with the network home directory. Question will reappear at next login.
Yes -- creates a local copy of the network home directory and a special local user account labelled "mobile."
Never -- suppresses this dialog at login to the machine and continues login to the network account using the network home directory.
Up through OS X 10.4.2, "Never" meant anything but never, as clicking the "Never" button did not prevent the dialog from coming up each time the user logged in. 10.4.3 fixed the problem, and "Never" became really never. But what if you change your mind and want to finally create a portable home directory on a machine where you previously discarded this choice? There aren't any controls to reset these settings, in either OS X Client or in OS X Server's Workgroup manager.
The solution resides in a preference file on the client machine: /Library/Preferences/com.apple.MCX.plist
When clicking "Never" in the startup dialog, OS X creates this preferences file (or an entry in the file if it exists already). This file contains an entry for each mobile user having chosen to never create a portable home directory on the machine. The key looks like this:
The value is set to 1 for each 'never' user. After deleting the file, the dialog reappears at login, and users can successfully create a portable home directory on the machine.
In case there are more than one entry, I guess deleting the key/value pair concerning just one particular mobile user, without deleting the whole plist file, would have done it also, but I did not try that.
I have seen many questions on various sites on 'how do I make my own theme in the Apple install of Blojsom in 10.4 Server?' Well, I dug around in the files for a day or two and here it is. BTW, as you can see, I'm still tweeking my own site.
Disclamer: If you destroy your Macintosh or anything else, don't blame me! Always consult a professional before attempting these modifications.