[luke]

Never mind, that just made it hand out the IP ending in .0 which is, uh, not what I want.

To answer my previous question, the daemon is bootpd and the config is in /etc/bootpd.plist. man bootpd says there is an “allocate” keyword which can be set to false. I haven’t tested it yet.

[luke]

I can’t say that I got too far. I installed Xsan and registered it. Then, as soon as I mounted an iSCSI volume through the Small Tree initiator, servermgrd started segfaulting repeatedly.

I have to shelve this experiment for the time being, but maybe I will try it again with the ATTO initiator when I have more time.

[luke]

What you need is a split-horizon DNS setup. Like jerkyjerk said, you should set up everything internally first and then poke holes in your NAT to allow certain things to come in from the outside.

Step 1: Set up your router
Assuming you’ve got a simple home router that does NAT and creates an internal network in the 192.168.1.x range and that its internal IP in 192.168.1.1… Log into it and turn off its DHCP server.

Step 2: Set up your server network settings
Static IP address: 192.168.1.2
Subnet Mask: 255.255.255.0
Router: 192.168.1.1
DNS Servers: 192.168.1.2 (Don’t list any others)
Search Domain: tmac.podzone.net

Step 3: Turn on it’s DNS server
Create one Primary Zone called “tmac.podzone.net.”
Make sure there is an entry for “myserver” which maps to 192.168.1.2
Also create a machine record for “router” which maps to 192.168.1.1
For good measure, add entries for all of your computers and give them IPs.

Step 4: Turn on it’s DHCP server and set it like:
Starting IP address: 192.168.1.100
Ending IP address: 192.168.1.200
Subnet Mask: 255.255.255.0
Router: 192.168.1.1
DNS Servers: 192.168.1.2 (Don’t list any others)
Search Domain: tmac.podzone.net

Go around to all of your machines and collect their MAC (ethernet) addresses. Enter each one into the static maps so that they will always get the same IP from your DHCP server (and it will be mapped to the right hostname by your DNS server).

Now you should have working forward and reverse DNS on your internal network. Each machine is looking to your server for DNS, so it’s like their own private club where they all know each other’s names like foo.tmac.podzone.net. Similarly, outsiders (who aren’t using your DNS server) won’t know their names, and won’t be able to connect to foo.tmac.podzone.net. With this, you should have no trouble setting up other services like OD, AFP, etc. for your internal computers.

We still haven’t done anything about external access. DynDNS is mapping tmac.podzone.net to your external IP… something like 24.17.26.164 maybe. This IP is actually pointing to your home router from the outside. You can log into your router and set up port forwarding. Forward port 80 to 192.168.1.2, and anyone going to http://tmac.podzone.net will get the website hosted on your server. The problem is that accessing http://tmac.podzone.net may or may not work, depending the way the NAT in your home router works. To fix this, you need to add a record to your internal DNS server to make tmac.podzone.net to map to 192.168.1.2.

This is the “split” of split-horizon. You have a single FQDN of “tmac.podzone.net” which resolves to 192.168.1.2 for your internal computers, and 24.17.26.164 for the rest of the Internet.

[luke]

I’ll be interested to hear how it works. Please let us all know what you find out!

[luke]

Out of curiosity, what iSCSI initiator did you use?

[luke]

Our IPs are segregated in such a way to ease future subnetting, so there are lots of big gaps. I suppose I could create dummy mappings for each of those IPs, but that hardly seems like much fun.

I’ve tried setting both the starting and ending IP address to a.b.c.0. That appeases the Server Admin GUI, and seems to work, but I don’t know what the daemon will think of that. Do you know what DHCP daemon Leopard uses? or where the “subnets” configuration is stored?

[luke]

That’s fantastic to hear. I’ve just gotten a trial for Xsan so I will try it against our native iSCSI targets.

[luke]

You need to use NFS to get that functionality. And understand that you’ll be giving up all sorts of security at the same time.

NFS trusts the clients to authenticate and authorize users, which means a rogue or compromised client can pose as any user and gain access to their files. To make NFS reasonably secure, you have to make sure you trust everyone who has root access on the client computers. You also have to make sure that only your trusted client computers can connect to your NFS server, and not someone’s personal laptop that they connect to your LAN.

AFP has its own means of authentication, so once it is connected for a given user, the _server_ enforces authorization on each and every filesystem transaction based on that user’s credentials. Since there seems to be no way to have multiple connections to the same server from the same client, only one user’s credentials can be used for the home directory mount at a time. If you have multiple home directory stores on different servers, you might be able to have one user from each store logged in at the same time — I haven’t tried that.

To make AFP home directories work with multiple logins, it would need to support multiple connections from the same host, the ability to mount subdirectories of shares, and some magic glue on the client’s automounter.

[luke]

I didn’t fully test this, but something like this should work if you type it into the script editor…

[code]set username to system attribute “USER”
mount volume “afp://hostname/share/” & username & “/”[/code]

[luke]

Double and triple check DNS. Is it possible that the 10.5 machine has two DNS servers set, but the first server has a wrong or missing entry for the LDAP server? Test this by using host or ping with the server’s fqdn from the 10.5 machine.

A next troubleshooting step would be to use the LDAP command line utilities on the client to query the LDAP server.

If those all check out, have a look at the AFP server that the home directories are stored on. Maybe the cause of the delay is from mounting it. Maybe it’s kerberos.

Logging in to a managed client is such a complex process, it could be any number of things…

[luke]

It would be nice if their pricing model made a little more sense. After paying, you get 90 days to download them all. That sort of implies that it’s not a “subscription” where you can keep downloading new videos as they release them.

Also, some videos have “Leopard” in their title but are dated before the release of Leopard. Were they created internally perhaps? Or are they mistitled?

Has anyone paid for these videos who can offer a bit of a review?

[luke]

Good to know…

There is definitely some magic here which is not well documented, and it works differently in Leopard as opposed to Tiger. See my other post here which addresses this sort of issue with other static mounts in /Network

https://www.afp548.com/forum/viewtopic.php?showtopic=19225

[luke]

Need more information…

I’ll assume you mean the users in your OpenDirectory and not local users. Did anything else disappear from OD like groups, mounts, computers, MCX settings, or just users?

Are the home directories of all those users still there?

[luke]

I called Apple’s corporate support today about this. They were able to recreate it in their lab in a few minutes and were surprised that this used to work in Tiger. They’ve opened a bug ticket to look into it and may fix it or else declare it as expected behavior.

So at least for now, a Leopard server will not be able to see its own shares automounted in /Network

[luke]

You could have each workstation share its own /Users directory to all other computers but putting them all into OpenDirectory as mounts. When you create a user in Workgroup Manager, you’ll be able to choose the home directory store that will be used, and you should see all of them from each workstation. The user’s home directory will be saved as /Network/Servers/primary.workstation.organization.com/Users/username/. On a workstation that is not their primary workstation, that directory will be available over AFP. On the primary workstation, that directory will be available because it will be symlinked to the actual /Users directory.

Autofs and automounter are both smart enough to NOT mount /Network/Servers/hostname/ from the server itself. Tiger could do this for everything in /Network, but leopard seems to only do this for the server’s entry in /Network/Servers

Of course, a much more reasonable way of doing this would be to use mobile home directories. Not only will you avoid home directory access over the network, you’ll still have them centralized on the server to make backups easy.

[Author]

Posts