DeployStudio, HP Layer 2 Switches and static addressed.

galwayguy85

Hi Guys.

I am hoping you can give me some advice here. I am reasonably au-fait with networking and the elements of the OSI model etc and I reckon I know already what is/isn't possible... a second opinion I'd still be glad of.

I work for a company that resells used Mac computers. We have a small workshop with a handful of HP switches and machines running OS X Server.

Currently we manage incoming stock by running 'System Report' on the incoming Mac and saving the file (containing serial numbers, RAM amounts etc) to the local server. Then we copy the serial numbers etc from the saved report more or less manually into the database system. Each mac gets its own unique article number, which references the system itself, when it arrived etc etc. All very tedious and prone to human error!

We also have a 'NetInstall' system in place that boots the incoming machine up to a network drive that then wipes the hard drive and then installs OS X onto it. All in all, about 30 mins is gone on this process despite have Gigabit ethernet switches and SSDs in most purchased machines. A total drag.

The boss man would like to make things more efficient.

He is proposing we use DeployStudio to manage both the capturing of the system details (via a special script) and then more-or-less automating the erasing of the HD and then imaging a copy of OS X onto the HD. I've tried this part out at home and whole thing is done in about 5 mins. A massive time saving.

One of the big caveats of the script is that a machine connected up to DeployStudio has to have a particular, fixed IP address (let's pretend, 192.168.1.10). It would get this from whichever port on the HP switch it is connect to. i.e the machine sitting next it to is connected to another port on the same switch and gets another different, specific IP address (let's say 192.168.1.12). When a third machine comes along and takes over the port that the first one had, it will get the same address the first one had to start off with...(192.168.1.10)

My big concern though is that switches don't normally care about IP addresses. MAC addresses are usually their thing. The switch in question is a HP 2530-24G J9776A. The vast majority of my research indicates that it is a Layer-2 only switch.

Am I correct in saying the above? Are there any work arounds to this? I can imagine it prob involves giving each port its own small VLAN (subnet 255.255.255.252). Getting a little out of my depth here! And I remember hearing that Netboot is difficult about booting to machines in different subnets?

Thanks for any feedback.

Cuddlesworth

galwayguy85 wrote: »

One of the big caveats of the script is that a machine connected up to DeployStudio has to have a particular, fixed IP address (let's pretend, 192.168.1.10). It would get this from whichever port on the HP switch it is connect to. i.e the machine sitting next it to is connected to another port on the same switch and gets another different, specific IP address (let's say 192.168.1.12). When a third machine comes along and takes over the port that the first one had, it will get the same address the first one had to start off with...(192.168.1.10)

Its a bad script then. IP's are either manually entered, in which case port doesn't matter. Or they are assigned, which is done by the DHCP server, which only cares about network segments and what details the device passed to it. So the DHCP server can be aware of a mac, and change it address. But that all seems pointless.

The script should just be entering a new database entry each time based on a unique ID like the serial, not basing itself off a variable like the IP.

galwayguy85

Hi Cuddleswoth

Thanks for that. I had thought nobody was going to give their two-cents worth!

I guess already that what you said would be correct. IP addresses assigned by ports on a switch kind of defeats the purpose of DHCP, doesn't it?

All the machines in the warehouse are tracked by 5 digit 'Article Numbers'. That is a record in the the database that contains the machines serial, date of delivery, OS version, remarks about it physical appearance etc.

The catch-22 situation we have at work right now, is that we want to use Deploystudio and a particular script to gather all system info (instead of manually copying and pasting into the database system, serial numbers in particular), but for this IP-address-based system to work we would actually first need (likely with a pen and paper) to record the ethernet MAC address and/or the machines serial number from the physical casing and input that elsewhere? A nuisance for iMacs as it printed on the underside of the display foot! And of course, Macbook Airs and newer Pros don't have ethernet ports. You can use an adapter of course, but that has its own MAC address, so in a single batch of incoming machines, the same MAC address may appear several time...

Heartbreaking! Technology should work for us. Not the other way around.

galwayguy85

The raison d'etre for trying to get IP addresses based on physical port from a given switch is that each IP address could be mapped to a given workstation on a desk. On a web dashboard, one could then easily see that a machine at given workstation had had its details captures, drives wiped, which version of OS X has been installed etc. All the while automatically creating an entry in the database and letting the worker get on with other things.

A pity that the whole thing has turned out to be a little impractical, as it is trying to turn the OSI model upside down (to a certain degree).

PeterTheNinth

From a high level point of view, I dont know anything about DeployStudio, but we did use a similar imaging software for PC called Clonezilla. The clients would PXE boot and download the image from the server. What we would find is that when the second PC would connect in to the server to download the image, the Gbps port that the server was connected to would split the traffic to the two workstation, so it would take twice as long to do two... i.e. the same time as it would have taken to do them individually. The solution to this was to use Multicast, which would allow you to send the same data to both machines at the same time.... (note that this would mean that you must send the same image to both workstations). There seems to be an option to do this in deploystudio. So that might be something to consider.

https://deploystudio.wikispaces.com/Multicasting+Basics


I'm not sure what you are saying with regard to the client having to have a particular IP address. Is this ONE particular IP address or range of IP addresses. I just dont understand what the restriction is, surely if it is on the 192.168.1.0/24 range, then it can communicate with anything from 192.168.1.1 to 192.168.1.254?

galwayguy85

Hi Peter

The restriction is more to do with the physical port on the switch than a given machine, per se. Locking IP addresses to the port helps to remove a whole amount of uncertainty as to which machine is where and how much of the workload has been carried out.

Everything would be in the normal small office LAN of 192.168.1.1 to 192.168.1.254

We would never have more than about 10 machines having theirs details captured (and then imaged) at a time. According to my studies on lynda.com of DeployStudio this is still short of the tipping point where it would make more sense to use multicast instead of unicast.

I will have a look at Clonezilla though.

niallb

Clonezilla is a great tool.

I use FOG for some PC labs for similar scenarios which has an excellent frontend and can run plugin scripts post install.
The unique ID is the MAC address of the ethernet card.

This is an interesting article on using Fog with Macs, and I think it might give you some ideas.

FOG on a MAC

PeterTheNinth

niallb wrote: »

The unique ID is the MAC address of the ethernet card.

See this is the bit that I don't understand about the system he is currently running. I dont have any scenario where it's practical to have to have particular IPs on the clients. I would always track machines by MAC address as that is the only address that you can be certain will not change.

I think what would probably be best in this scenario would be to step back for a second, and take a wider overview of the system in place. I find that when you are working with a system for a long period of time, you very quickly can't see the forest for the trees. And you begin working within the confines of your particular system as opposed to seeing the bigger picture.