- download OSXvnc

- Move diskimage to remote computer

scp OSXvnc1.5.dmg admin@thatmac.fooschool.edu:~/Applications/

- ssh to remote comptuer, go into Applications folder, mount dmg file, go into .app folder

open OSXvnc1.5.dmg

cd OSXvnc.app

- start the binary over ssh. The localhost option sets it up to sshtunnel.

./OSXvnc-server -localhost

- establish ssh tunnel from local computer

ssh -l admin -L 5900:127.0.0.1:5900 thatmac.fooschool.edu

- start local vnc client to localhost

vncviewer 127.0.0.1

SSH will tunnel the vnc client to the service you started on the remote comptuer. It should pop up. It’ll be slow. But it works.

Lost a few hours today over a stupid mistake, getting SSL/TLS running on Openldap. When I tried:

 ldapsearch -x -Z -h woodsy.nicholas.duke.edu -d 1 

I got:

ldap_bind: Can't contact LDAP server
        additional info: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure

Over and over, I was troubleshooting the certificates, since that’s the common problem. Certificates were fine, and the debug info suggests that it hasn’t gotten to the certifacate handshake anyways.

Anyways, the dumb error was in slapd.conf

When I uncommented the lines giving the path to the certificates:

TLSCertificateFile /usr/share/ssl/certs/slapd.crt
TLSCertificateKeyFile /usr/share/ssl/certs/slapd.key
TLSCACertificateFile /usr/share/ssl/certs/server-ca.crt

I’d left the leading spaces, so the configuration parameters weren’t even loading. Hint: don’t do this.

Users keep loosing thier duplexing options from our samba print queues. I haven’t solved the problem, but this is what I’ve learned.

We provide print queues that are described by Microsoft as “Point ‘n Print”.

A point ‘n print queue spools print jobs that have been formatted by the workstation.

The workstation learns how to format the job by downloading a print driver during the first connection.

The print driver doesn’t automatically know if it can submit duplex jobs, however. It’s up to the print server to hand off the driver, but also hand off some subsquent info about what options on the print device are available. Like a duplexer or extra paper trays or evelope feeders.

So when a user makes a printer shortcut in their account, they are storing three things

- The UNC path to the print spool- \\SAMBASERVER\printername

- A copy of the print driver, a file that they will carry around in their profile

- some device configuration options which modify how the driver will appear to them. This is stored in the Windows registry in long unfreindly string:

HKEY_CURRENT_USER\Printers\DevModePerUser\”\\SAMBASERVER\printername”

That last bit is what keeps vanishing. That’s what puts a check in the duplexing checkbox.

The problem seems to be that workstations are somehow not setting that registry key, or are overwriting the user’s version of that key.

The machine stores the devmode in

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Print\Providers\LanMan Print Services\Servers\[server name]\Printers\[name of queue]\Default DevMode

I’m thinking, in looking at some computer registries, that the problem might be that the comptuer is looking to saint.env.duke.edu for the devmode information, rather than nicknet.env.duke.edu, which is a virtual samba server on saint.

But I can’t tell for sure. One user told me that her duplexing comes and goes from certain machines. I’m not sure what we’d have to clear out to get those bad settings from the local system, or if moving nicknet to another server will fix it.

use client driver = yes

which I’d added in to get past an earlier roadblock I had on the live machine. I hadn’t need the parameter on my test machine, and naturally, it seems to disable clickable driver download.

So here the relevant params…

[global]

        load printers = yes
        printing = cups
        printcap name = cups
        show add printer wizard = yes
        lpq cache time = 100

#shares 

[printers]
        comment = all printers
        path = /var/spool/samba
        browseable = no
        public = yes
        guest ok = yes
        printable = yes
        printer admin = print-admin

[print$]
        comment = Printer Drivers
        path = /var/lock/samba/printing/drivers
        browseable = yes
        guest ok = no
        read only = yes
        write list = print-admin

I’m storing the printer drivers in the same path as the runtime tdbs.

I could get everything to work on our PDC, except for the assignment of Window print drivers to the cups print queues. I couldn’t get to work from the “Add Printer Wizard”. I got a “Printer settings could not be saved. Access is denied.” error. Got the same thing from the command line, using rpcclient. As far as I can tell, there is no way to perform this action directly on the tdb file which hold the data. It must be done though system calls.

My guess is what’s keeping it from working is that the smb.conf file that’s governing this is a second smb process I run independant of the PDC, on a virtual ethernet interface. I wonder if the RPC calls are going back to the main interface, somehow.

The verbose output from pdbedit is kinda screwy; here’s some code to pluck out specific values- I’ve wanted to be able to grab “Account desc” for sorting users as I migrate them.

#!/usr/bin/perl
#parse a verbose pdbedit record
#put record keys and values into a hash

#pdbedit command- change for your system.
$pdbedit = '/usr/local/sbin/pdbedit -s /etc/samba/pdc/smb.conf';

foreach $username (@ARGV){
        open (UREC, "$pdbedit -v $username |");

        foreach (){
                chomp;
                #split key from value
                @line = split(/: /);
                #looks like the values are formatted with whitespace
                #take out the leading whitespace
                $line[1] =~ s/^\s+//;
                $urec{$line[0]} = $line[1];
        }
        close (UREC);

        #example output
        print "$urec{'NT username'}\n";
        print "$urec{'Full Name'}\n";
        print "$urec{'Account desc'}\n";
}

I’ve seen two cases recently where a user couldn’t authenticate to our servers when they accessed our network from non-domain computer, unless they mapped a drive. They couldn’t do it through unc path shortcuts, although one reported that she did so as recently as two weeks ago.

In other words, most XP computers had no problem with a Start->Search->Search for Computers to bring up \\server.domain.edu They’d get prompted for a login screen, do the DOMAIN\user44 thing, and they’d be in.

But with these two users, they could only do it by mapping a drive to to our domain, and supplying credentials in the “connect as other user” screen.

Watching the logs on the servers the users were attaching to, it looks like the user attempting to attach was authenticated not with the credentials they entered, but with their local user account “nickname”

In this line from the logs, “Chingay” was the nickname of the user account. In XP, the user can have a friendly, real world name with a space, and I guess the nickname was equivalent to the real “username”.

[2004/03/18 10:42:16, 0] smbd/password.c:domain_client_validate(1620)
domain_client_validate: unable to validate password for user Chinggay in
domain KLJAYME to Domain controller pdc.domain.edu. Error was
NT_STATUS_NO_SUCH_USER.

I think what these computers have in common is that they were both XP Pro in fast-user-switching mode. It must have something to do with the “friendly” login names XP creates during the install. What is strange is that our server prompts with an authentication screen, but XP fails to use the credentials entered.

A problem cropped up this morning when some home directories were migrated to a new server. Two users reported problems with Excel and Word files crashing. We narrowed it down to files edited and saved by MS Office 2000. The same files edited in OpenOffice didn’t have the problem. After saving the files, the permission mask got set to -r——–.

It was odd, because the problem was easy to reproduce on this server, but not on the original host of the home directories, which had an identical smb.conf.

Turns out that the new server had an rpm isntalled of Samba 2.2.7 , where our other servers had a locally compiled version of 2.2.8

When running testparm on the two installations, the newer install offered this parameter-

 acl compatibility = 

…set to null, apprently, but it did make a difference. When I installed 2.2.8 on the problem server, it fixed the error.

This recent samba list thread seems to report a similar problem, though the workarounds are done by forcing the mask-

http://lists.samba.org/archive/samba/2004-March/081690.html

We don’t force many permissons on our shares. Here’s the config of the share that had the problem.

[home6]
        comment =  Home Folders
        path = /slot1/p1/nickhome6
        read only = No
        create mask = 0770
        profile acls = Yes