[gw1500se]

Just another note to add more confusion to the mystery. If a user is having the font problem and moves to another client machine, the font problem does not occur. If a user, that is not having that problem on their client machine, logs on the the problem client machine, that user does not have the problem. Weird.

[gw1500se]

We’ve had good luck with Iogear’s MiniView Ultra+..

[gw1500se]

Various problems all are non-descript. For example extemely slow performance with activity monitor showing minimal cpu and disk activity. Same user on a different client machine worked fine. Erase install cleared it up.

Another user could not run mail, it would just hang unless the user logged on with a different client. Again Erase install cleared it up.

Yet another user had corrupted fonts. Erase install.

The list goes on. It was not worth fighting so we just did erase installs on all. No problems.

[gw1500se]

We’ve tried doing upgrades on client machines and have yet to succeed. Odd behavior occurs that we cannot clear up without doing an erase install so we have given up doing upgrades. I am afraid to try it with a server because that is much harder and traumatic to rebuild from scratch.

[gw1500se]

I found the problem. I am too embarassed to tell you what it was. Call it a senior moment. Sorry for the bother.

[gw1500se]

As suspected, the quotes did not help. This is so strange since it works from the command line.

[gw1500se]

I’ve run it as both root and admin. Both behave the same. I’ll give the quotes a try but I can’t see how that would cause scp to prompt for a password.

[gw1500se]

The cables that come with that card have the correct ends for the Xraid (the G4 card ends and the Xraid ends are different, G5 is all the same). There is no issue other then the physical connections.

[gw1500se]

We experienced the same problem until we got our LDAPv3 binding straightened out. You may have a different problem but I suspect it is stiil related to binding. The clients were 10.4.2 and the LDAP server 10.3.9. We serve out the binding information via DHCP and it turned out 10.4 clients did not like the way 10.3 DHCP did it. In order to work around it we had to go to each client’s directory access utility and configure the LDAPv3 binding manually. I have no idea what is different between doing it manually and letting DHCP do it but that cured the problem. We will be migrating to a 10.4 server next weekend and DHCP binding works fine there so we have to go back and undo all that.

[gw1500se]

Although incomplete at this point here is the script:

#!/bin/bash -x
#

dirlist="/usr/local/bin /usr/local/sbin"

for this_dir in $dirlist ; do
	files_here=`ls $this_dir`
	files_there=`ssh [email protected] "ls $this_dir"`
	for this_file_here in $files_here ; do
		scp -p $this_file_here [email protected]:$this_dir
	done
done

The ssh works fine. The scp prompts for a password.

[gw1500se]

Thanks for the reply. I do indeed have ssh keys set up . I can ssh and scp from the command line with no problem. Also I can use ssh in a script but not scp. The command is quite simple:

scp -p /usr/local/bin/somefile [email protected]:/usr/local/bin

Of course the script uses variables but the resulting command is the same.

[gw1500se]

It won’t work. You need Apple part M8940G/C for a G4.

[gw1500se]

[QUOTE BY= None] Try starting it like this:

/usr/local/mysql/bin/mysqld --basedir=/usr/local/mysql --datadir=/usr/local/mysql/data --user=mysql

[/QUOTE]

Thanks, this was the key. It finally gave me an error message that told me what was wrong. I had to fix a permissions problem and now I’m up an running.

[gw1500se]

Not having heard from Bo_S is there anyone else that can help me. I have gone through several rounds of uninstalling and installing with no success. Its the same problem every time. After running ‘configure’ I run ‘bin/safe_mysqld’ which outputs the ‘Starting’ message then immediately outputs the ‘STOPPING’ message. No errors and no logs, that I can find, to tell me why it won’t run. TIA.

[gw1500se]

Thanks for all the clarifications. However, I just have a couple of rhetorical questions.

[QUOTE]If there wasn’t a very high probability of the keychain holding the user’s credit card and bank info, from when they surf the web, I’d agree with you that the Keychain’s security is less of a concern than the user’s password.[/QUOTE]

Why should this not be the systems admin’s decision?

[QUOTE]If you want to go that route, just set up Safari to not save anything. Turn of auto-fill, turn off cookies and throw away keychain manager.[/QUOTE]

Safari is not even an issue here. What about other applications that don’t provide that feature?

[Author]

Posts