Mac support
-
I’ve begun work on this and added the necessary GUI elements already.
I can create the session and cancel the session. There is no need for the storage group or the os parameters in scheduling this as the group and os are stored with the image.
I’m not going to create the fog.mcupdate or mcTask.php file as I can do all of this from the ipxe menu.
This is just a checklist for me to follow, the multicast stuff is not operational from a name joining setup yet.
-
Ok so here is the requested diff file. I had to zip it in order to upload the file. So I hope this helps. I look forward in seeing the final product!!
[url=“/_imported_xf_attachments/1/1260_joinMC.diff.zip?:”]joinMC.diff.zip[/url]
-
[quote=“fractal13, post: 34855, member: 24300”]TS: The FOG service for Windows is under active development in C#. So, we won’t be using that code for OS X/Linux. I would encourage you to consider C. That will be at least a portable as Java, if we static compile it. It will be easy to write a simple service like you’re talking about being a wrapper for shell scripts. I could give you some boiler-plate networking code and give advice on invoking shell scripts from within, if you want it. This is something I’ve done in previous projects many times.
Thanks for all of your help.[/quote]
Fractal13
I get what you are saying about using C. My only point was if I where to write it in java and got a working app, adding the windows version would a piece of cake and then fog would have a single executable for all os types one Maven or eclipse file rather than a VS project and an xcode project and a another for the various flavors of nix. I know a lot of people are not very happy with java so thats why I asked.Nonetheless I can write it in C and keep you all informed. Is an xCode project acceptable for submittal?
I feel this forum proves why open source Rocks!!!
Thanks,
TS -
ONly problem I see with using the java approach is it would assume all users always have a version of java installed. Issue I foresee, beyond windows admins who don’t allow java because of security concerns, is what about linux non-gui installs? How would the app function then? Couldn’t the linux/mac service just be a series of scripts that are controlled through at or crontab?
-
I’ve now got it to a workable state where you can join existing sessions based on the session name. You can delete the task from the link, and added db updates to add the session password and maxwait fields where appropriate.
I haven’t added, yet, checking on the session password as I just want to make sure the menu system is working.
-
@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
-
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, 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 -
No it doesn’t though I suppose I could add that feature.
-
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.
-
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).
-
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.
-
[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
-
[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.
-
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
-
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.
-
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 -
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 -
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=“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.
