Mac support

Tom S

@Tom Elliot
Your Java statements are 100% correct and valid. One thing Mac does well is supplying a shell acceptable way to manipulate almost every aspect of the machine’s configuration. Since the arrival of ARD, you can find scripts for almost everything. As far as using cron jobs for the fog service on os x and nix, I would steer more toward daemons. In os x, there are 4 levels of daemon. Ones that run when machine boots (via launchd) and ones that run at user login (launchctl). The naming, binding, and other administrative tasks would run as root in a daemon. The gui would run at user login.

Would wget with https work for communication between server and client? If not, apple does supply some safari based C libraries.

Printers. Since both nix and os x use cups, this should be pretty straight forward. I would suggest users supply a package file with the drivers or the actual ppd/gz file through the web gui. Install package or use wget to download ppd to printer/ppd folder and then run script to install printer.

So if you all are ok with a bash daemon that periodically probes the fog server cool, I can start adapting my scripts to work with your current service pages on fog.

Side note… same kind of service could install software too. Just sayin

TS

Tom Elliott

If you’d be willing TS, Can you try svn of fog?

Test it out. There are a few bugs I’m aware of right now, such as the FOG Service stuff. Also, session password setting doesn’t work either. I’m still working that out. WHen I get it working all should be well.

But give it a go. Most of my implementations have been based solely on adding the ability to join multicast sessions. This joining is only relevant from the session generated from the Image Management Page. You can only add hosts, right now, from the ipxe menu. There is a login required to get to the Multicast Join field to add some layer of security, but hopefully this will be okay. I don’t think we need the session password, necessarily, if we have the login parameter in effect. What do you think?

Tom S

[quote=“Tom Elliott, post: 34911, member: 7271”]If you’d be willing TS, Can you try svn of fog?

Test it out. There are a few bugs I’m aware of right now, such as the FOG Service stuff. Also, session password setting doesn’t work either. I’m still working that out. WHen I get it working all should be well.

But give it a go. Most of my implementations have been based solely on adding the ability to join multicast sessions. This joining is only relevant from the session generated from the Image Management Page. You can only add hosts, right now, from the ipxe menu. There is a login required to get to the Multicast Join field to add some layer of security, but hopefully this will be okay. I don’t think we need the session password, necessarily, if we have the login parameter in effect. What do you think?[/quote]
@Tom Elliott
I agree with using the hide menu function in ipxe (username and password) if someone wants to password protect it. The name in a way is a password if you think about it.

I will definitely check out the svn a little later. Does the current code allow for non-registered clients to join?

Thanks,
TS

Tom Elliott

No it doesn’t though I suppose I could add that feature.

Tom Elliott

For right now it’s only registered hosts. I have to think of the logic to get the non-registered hosts to join the task as I have to falsify a tasking much the same way capone falsify’s a tasking.

Tom Elliott

Before I go adding support for “non-registered” hosts.

I’m going to first add a field to allow groups or host to join previously created sessions so you can schedule registered hosts from the gui. Don’t know why you’d want to do this method of multicast, but if this is worth doing, it’s worth overdoing (mythbusters is my favorite).

Tom Elliott

A caveat to all of this information.

Right now, although it’s only enabled for registered hosts, it does not need any modification to the init files. Though I will probably need to add support for the OS type of Mac OS, if you just need to get it working, you can test with windows or linux. Hopefully, soon, I can remove even the need for the OSID as all it’s used for is to determine partition layout on the Resizable image, and even then, it’s only specific to Windows Partitioning layout. It’s not used for MPS,MPA, or Raw image types.

So if you have a Mac OS image, partclone already is aware of the file type. The OSID has no impact on how the system will run if it’s MultiPart single/all disk, So you can essentially assign linux os to mac os image and all should work properly. We create a copy of the GPT/MBR information which is what get’s restored to the hdd on download. So things should all work properly anyway.

Tom S

[quote=“Tom Elliott, post: 34918, member: 7271”]For right now it’s only registered hosts. I have to think of the logic to get the non-registered hosts to join the task as I have to falsify a tasking much the same way capone falsify’s a tasking.[/quote]
Call me crazy but could you…
Select Join Multicast from ipxe. ipxe sends mac address to php. If not registered, php sends back to ipxe. ipxe asks for computer name. Enter in computer name and maybe os type. ipxe then asks for confirmation, then send back to php. Php creates host, then creates task for multicast session. Maybe protect the final step with fog username and password. Or possibly send client to fog.man.reg then onto multicast.

I think this sort of registration process would be pretty cool!!

When multicasting a large organization, as I am sure you know, knowing EXACTLY what machines will join the multicast session is impossible without touching machines multiple times. So being able to join any machine to multicast is I think key…

Side note, as you said earlier the funcs.sh file still needs editing. If os is unknown, if I remember correctly it will fail!!

Anyways awesome work Tom!!

TS

Tom Elliott

[quote=“Tom S, post: 34924, member: 25305”]Call me crazy but could you…
Select Join Multicast from ipxe. ipxe sends mac address to php. If not registered, php sends back to ipxe. ipxe asks for computer name. Enter in computer name and maybe os type. ipxe then asks for confirmation, then send back to php. Php creates host, then creates task for multicast session. Maybe protect the final step with fog username and password. Or possibly send client to fog.man.reg then onto multicast.

I think this sort of registration process would be pretty cool!!

When multicasting a large organization, as I am sure you know, knowing EXACTLY what machines will join the multicast session is impossible without touching machines multiple times. So being able to join any machine to multicast is I think key…

Side note, as you said earlier the funcs.sh file still needs editing. If os is unknown, if I remember correctly it will fail!!

Anyways awesome work Tom!!

TS[/quote]

One of the coolest features of ipxe is we already know whether or not the host is registered when it first starts. While we originally toyed with the idea of having ipxe auto register the host, the reason we went against it is because of compatibility issues within the OS layer of FOG.

I’ve added the Apple Mac OS to the list of OS’s but I have not incorporated it into fog quite yet.

I think I have another method around having a non-registered system join an existing multicast task. The method will not require generating a task in and of itself and should still work, if the host is compatible with fog. I will look into doing such incorporation with the ipxe system for un-registered hosts. However, I may wait a couple of days if you’re willing to wait as well. Only reason, this incorporation today took a lot out of me mentally speaking. I just need a day away from all the testing and multicast stuff. Personally, it’s not one of my favorite areas.

Tom S

TAKE A BREAK.
You have done a lot on Fog over the last few months!! I think we have some good areas to start testing with. Machine types, multicasting and everything else for macs. I am pulling all of my scripts together and comparing the logic between the Windows service and how it talks to fog. It will take me a few days to get things worked out but I can at least get the scripts all compliant with fog and then we can just worry about the service wrapper and gui!!!

I hope that you are getting the praise you deserve for picking up this project and starting the fire under the fog community’s butt. Given the talents of the people using fog…skies the limit!!!

Thank you Tom,

TS

Tom Elliott

To be fair,

I’d highly recommend you don’t use the current FOGService files to compare against. We’re in the process of testing a new build for this. So much of what’s in those folders will soon be irrelevant as we’re modularizing it.

If you need the links we use to get the services and how to interpret them, I can help you there. I’d highly recommend that you start from scratch rather than trying to follow the current code base as they’re to completely different systems.

Tom S

I am mostly looking at the responses from the fog server. I have a list of links awesome. I already have the hostname changer and LDAP binding done.

Right now I am looking at the INI file. Are we going to keep these setting names?

Thanks
TS

Tom S

Ok so I have been working pretty hard on the OS X service!!! I have implemented most of the modules at this point. I am skipping the host screen resolution out for now (OS X is very picky about screen resolution and there is no native command for this, however there are gpl open source ones out there). I will need to add a new printer type to the PrinterManager page to support the OS X cups printer. I am going to start soon on the gui.

@Tom Elliott
When I send an action to usertracking.reports.php ( I am base64 encoding the info) everything seems to report fine but I get “Array” for the username. Any ideas? I have checked that the value of the user parameter is correct.

Anyways I will have some uploads this weekend for you folks!!

Thanks
TS

Tom S

Just about finished. I feel I just wasted a day working on FOGCrypt for os x. It seems that the way FOGCrypt encrypts is not very compatible with other AES encryption tools. It has to do with the way the stream is handled as well with the key and iv generation.

@ Tom Elliott
Previously you mentioned a major rewrite of the Fog service. was coming Is the FOGCrypt slated for a revamp as well? Possibly using a free library would work better than Window wrappers or using another encryption method like CBC. I could write another encryption tool using an openssl wrapper, but I would rather make the windows generated password cross platform.

Thanks
TS

Tom Elliott

[quote=“Tom S, post: 35378, member: 25305”]Just about finished. I feel I just wasted a day working on FOGCrypt for os x. It seems that the way FOGCrypt encrypts is not very compatible with other AES encryption tools. It has to do with the way the stream is handled as well with the key and iv generation.

@ Tom Elliott
Previously you mentioned a major rewrite of the Fog service. was coming Is the FOGCrypt slated for a revamp as well? Possibly using a free library would work better than Window wrappers or using another encryption method like CBC. I could write another encryption tool using an openssl wrapper, but I would rather make the windows generated password cross platform.

Thanks
TS[/quote]

FOGCrypt will no longer be a part of the FOG Service under the new fog service. We’re going to be using AES-256-CBC encryption which requires a 32 character key and an initialization vector (iv) to decrypt. Jbob and I have already tested encryption and decryption of this traffic. To further secure the code bits, we’ve actually added 2 keys. One to encrypt the traffic being passed AND one to encrypt the FOG_AD_DEFAULT_PASSWORD field. One to encrypt the traffic being passed. We’ve also tested both the encryption/decryption AND both at the same time. The ADPass field will always be encrypted.

With all of that, the iv and encrypted data are always passed together to allow the decryption of the data being sent. You may want to PM me or google chat me if possible so I can further assist you with this.

Tom S

I know I know, I am late…:) School is starting back up at work and I have a couple hundred teachers running around asking what their login passwords are. Needless to say, I have been busy dealing with stuff that makes my head hurt… ah the Academics

Anyways, I have the source and binary ready for you all to test out. Since the file is larger than what is permitted on this forum I have posted it on Google Drive. Please understand that the source code is only in its infancy and much debugging is still needed. The zip file contains a dmg file with the actual compiled binary. The source is located in the src folder. I did not include any xcode projects as they are only a GUI wrapper for the bash scripts. I have included a readme file that I think is really important for any of you that are thinking about getting this going to read. Hopefully, as this community as already proven, we can collaboratively get this going so that it may be entered into Fog’s releases.

I am not a proud man, so if the code needs rewriting or totally redoing, I do not care. I just hope people find it useful and helpful in getting true Mac support into fog.

The zip file is located [URL=‘https://drive.google.com/file/d/0BxXg3SQONbFIRnhqNDJXeFBGYjA/edit?usp=sharing’]here[/URL]

Thanks,

TS

Dave Smith

Thanks Tom S. I will down load and give this a try.

Tom S

Sorry everyone, I had to reupload. I forgot to uncomment some commands. The link is now correct sorry. I guess thats what you get when you upload at midnight o_O

Tom S

So I have some things to update here. Maybe some are already doing this, if not I hope this helps others.

I have been messing around with the mac efi booting of ipxe a lot. To summarize (again probably well known), Macs are very crazy when it comes to efi booting. Some can run 64 bit OS but not 64 bit efi, some use 64 bit efi but only boot 64 bit OS if you unlock it. While most modern macs boot pure 64 bit architecture. This I found was a pain when trying to get the older macs(pre 2010) to netboot to fog. I had already been able to get a mac to netboot to tftp and ipxe.efi like explained earlier in this forum, but I could not provide images of the ipxe 32 and 64 bit efi simultaneously using isc-dhcp or a Windows dhcp server. Well till earlier today. So I will explain how to provide netboot for both 32 and 64 bit efi through isc-dhcp-server and how to embed the ipxe efi on the efi partition on the mac for use in a Windows dhcp server. So here we go:

If you are using isc for dhcp leasing, I found that trying to provide a true BSDP service was going to really suck because Apple doesn;t really adheare to DHCP “rule” during the entire boot process leaving isc holding the bag after the initial request was made. I found that the only way to determine the correct efi framework was to do so by the model id that Apple uses in the bsdp request.
Below is a sample config file for isc dhcp:
[CODE]# DHCP Server Configuration file.

see /usr/share/doc/dhcp*/dhcpd.conf.sample

This file was created by FOG

use-host-decl-names on;
ddns-update-style interim;
ignore client-updates;
next-server 192.168.1.1;

subnet 192.168.1.0 netmask 255.255.255.0 {
option subnet-mask 255.255.255.0;
range dynamic-bootp 192.168.1.10 192.168.1.254;
default-lease-time 21600;
max-lease-time 43200;
option domain-name-servers 127.0.1.1;
option routers 192.168.1.1;
filename “undionly.kpxe”;
##filename “pxelinux.0”;
}

allow booting;
authoritative;
class “AppleNBI-i386” {
match if substring (option vendor-class-identifier, 0, 14) = “AAPLBSDPC/i386”;
option dhcp-parameter-request-list 1,3,17,43,60;
if (option dhcp-message-type = 1) {
option vendor-class-identifier “AAPLBSDPC/i386”;
}
if (option dhcp-message-type = 1) {
option vendor-encapsulated-options 08:04:81:00:00:67;
}

    if (substring (option vendor-class-identifier, 15, 7) = "iMac5,1"){
            filename "ipxe32.efi";
        log(info,concat("Received BSDP REQUEST ",substring (option vendor-class-identifier, 15, 10)," using 32 bit EFI"));
    } elsif (substring (option vendor-class-identifier, 15, 10) = "MacBook2,1"){
          filename "ipxe32.efi";
        log(info,concat("Received BSDP REQUEST ",substring (option vendor-class-identifier, 15, 10)," using 32 bit EFI"));
    } elsif (substring (option vendor-class-identifier, 15, 10) = "MacBook3,1"){
          filename "ipxe32.efi";
        log(info,concat("Received BSDP REQUEST ",substring (option vendor-class-identifier, 15, 10)," using 32 bit EFI"));
    } else {
            filename "ipxe.efi";
        log(info,concat("Received BSDP REQUEST ",substring (option vendor-class-identifier, 15, 10)," using 64 bit EFI"));
    }

}

allow unknown-clients;
[/CODE]
If you look at the config above, notice a reoccurring:
[CODE]} elsif (substring (option vendor-class-identifier, 15, 10) = “MacBook2,1”){
filename “ipxe32.efi”;
log(info,concat(“Received BSDP REQUEST “,substring (option vendor-class-identifier, 15, 10),” using 32 bit EFI”));
}[/CODE]
You would need to add a new occurance for your model id. Replace the MacBook2,1 with what is recorded in your syslog file. The number 10 will also need to be changed to the length of characters in the model id taken from the syslog. Add your changes and run sudo service isc-dhcp-server restart to make changes final. I feel this approach is not that bad for isc. Since MOST post '09 device support 64 bit efi. You would only need to make changes for the older devices.

Ok for Windows DHCP. This approach doesn’t not include any dhcp modification at all. Since Leopard GPT tables have been pretty standard or required in later versions of X, we can use one of the hidden partitions found on an OSX hard drive. Now I have added this to the service I wrote and added some other changes, but it at least automate the process. But for those who just want to try it out here you go. In order to get a 32 bit version of ipxe.efi please visit [url]https://rom-o-matic.eu/[/url] and build it there (Do not forget to add Fog’s ipxe script, look in the svn)

First lets find out what version of the efi you have. Run this command in the terminal:
[CODE]ioreg -l -p IODeviceTree | grep firmware-abi | cut -d \ -f 11[/CODE]
It should contain EFI64 or EFI32.

Next lets get mount the efi partition and create the correct dir structure:
[CODE]diskID=$(diskutil list | grep EFI | grep -o ‘(disk[0-9s]*)’);
mkdir /Volumes/efi;
mount -t msdos /dev/$diskID /Volumes/efi;
mkdir /Volumes/efi/System;
mkdir /Volumes/efi/System/Library/;
mkdir /Volumes/efi/System/Library/CoreServices/; [/CODE]

Finally add the correct ipxe efi to /Volumes/efi/System/Library/CoreServices/boot.efi. The file name must be boot.efi. If not, it will not work. This basic setup does not show up in Starup Disk in the System Prefs but will when holding down option at the boot screen. The version I have added to the service does show up with the Name “Fog Boot”.

If and or when ipxe decides to support reading of an ipxe script from a local partition this way would be cool for ethernetless macs. Add your own script on the efi partition that joins a wireless network and then proceeds on to fog. Anyways that’s in the future

I will have an updated service online soon.

Thanks,
Tom S

steve

Thanks Tom S

Mac support

see /usr/share/doc/dhcp*/dhcpd.conf.sample

This file was created by FOG

171

11.6k

17.1k

154.6k