[andrina]

Have you tried throwing in the expect script for a test? Also, what the default shell you’re using when testing interactively? Is it the same shell you script in? Anything significant/custom in your interactive environment that isn’t getting translated into the script? Also – in my last note – along with the quotes I’d removed the “user@” portion of the scp – did you try that?

[andrina]

Is the script being run as the user admin? Try replacing your scp with the following:

scp -p $this_file_here myremote.mydomain.com:”$this_dir”

[andrina]

I normally try to avoid using ssh and scp in a shell script – try using something like expect instead – i.e. (the $argv 0 is going to take the password from execution of the file):

#!/usr/bin/expect
spawn scp /path/to/file user@machine:"/path/to/directory/"
expect "ssword:"
send [lindex $argv 0]\r
expect eof                                                                                   

Course – this is all assuming you don’t have ssh keys set up – assuming you have keys set up – what does you scp line look like?

[andrina]

Indeed, a few more details of your issue would be handy, but in the meantime – where are you storing your FCP project files (How is the drive formatted?) What kind of home directories are you using (local/networked?) If you’re using network homes, are they AFP or NFS? Do you have any NFS mounts on the FCP workstations?

[andrina]

Are you looking as POSIX permissions or ACLs?

[andrina]

Is something like Arek’s Centralized logging what you’re looking for? Or perhaps an scp command in your script? i.e.:

scp -r /path/to/file [email protected]:"/path/to/remote/location"

[andrina]

How are your clients authenticating? Is this a local authentication, or from a server? Can any user log into these machines (if you have multiple user accounts)? In a case where no user account can log into the machine and if your machines have local authentication, and have done their daily cron jobs there will be a backup of the nidb – look at /var/backups/local.nidump, and check the date on it – if it’s pre-power outage, then you’re in luck, and can follow one of the many methods out there for backing up from this file. All that may not solve your issue, but it’s a start – I’d also suggest backing up the whole machine before trying any messing with the netinfo database.
Cheers,
Andrina

[andrina]

The new PCI ATA card would certainly help you out, but the other thing I’ve come across (also having the service centre background like Josh) is the magic 8GB partition…. If you partition your drive so the first partition is no larger than 8GB, and install your OS on that partition it should clear up your issues… there’s something about system files being moved out of that 8GB space over time and leading to an unstable and unbootable system without the partition… There’s a lot of discussion around about this really only being valid on the beige G3 generation, but with your machine being a rev A B&W I’d be suspicious…
Cheers,
Andrina

[andrina]

So, your server’s WorkGroup Manager should indeed be pointing to 127.0.0.1, as well as Directory Access on your server – only your clients should be pointing to the IP or FQDN. So, to answer your initial question, your user records should be in /LDAPv3/127.0.0.1. As for the client machines seeing the server – how long are you waiting after booting the machine before trying to log in as a network user? Try some troubleshooting techniques on your client systems, like killing the DirectoryService process, or taking a look through ‘dscl localhost’ – you should be able to navigate into your LDAP structure and see your users, if not it may give you an error message that will point you in the right direction.
Cheers,
Andrina

[andrina]

I think you should be able to do the following:

ldapsearch -h server.example.com uid=user dn

[andrina]

Well, I wouldn’t do this on a production machine, but seeing as it’s a testing server on your powerbook…. try playing with the nidb a bit – you can either try restoring your previous local.nidb from /var/backups, or whip the feet right out from underneath it, and completely remove the nidb – take a note before you do this about UIDs and usernames that exist in your nidb. I can’t stress enough that this does of course have the potential to completely wreck your testing machine, but as you can’t log in at the moment, and it’s a testing server, I’d play with it just for fun! If this is all new to you, there’s several guides around for reinstating your nidb from backup – just google it. And if it all falls down around you, you still have the image that you created your testing powerbook from in the first place, restore and start again… 🙂

[andrina]

rather than passwd, try NeST:

NeSt -hostpasswordserver []

[andrina]

[QUOTE BY= gbsa]The Xserve has starting sending emails “Server Problem Notification” regarding an enclosure intrusion.
However, no one has been near the server.[/QUOTE]

Make sure the server is seated firmly home in the enclosure – I’ve had this just happen over time, especially if your server screws aren’t done up tightly. Simply opening and closing the server may just clear this up for you.

[andrina]

Have you checked in /Library/Logs/AppleFileService/AppleFileServiceAccess.log or /var/log/system.log for PasswordService requests to see if the server is seeing the authentication?

[andrina]

Have a look at Activity Monitor – it’s very easy to see from there what the parent process of your sed/find/perl/sort process is if you inspect the suspect process. Should help you search out what exactly is hitting your drive so hard.

[Author]

Posts