Winding up to 1.6

[larkost]

I have left the version number at 1.6 for a long time now, and I think that it is time to push out another non-svn build, so I am going to put a cap on 1.6 pretty soon. It will probably be sometime after my presentation at MacSysAdmin next week, but I want to get things wound up then. So if people would test on the current svn version, that would be great. I will be making a couple of changes before finally wrapping up, but neither should affect most testing. So everyone get cracking.

Oh, and I plan to re-arrange some things with the 1.7 series. So be on the lookout for some re-structuring of the folder layout at that point. InstaUp2Date will be moving out of the AddOns folder (which will probably collapse), and start to take center stage.

[dead2sin]

I noticed on one of the more recent SVNs you can specify which build numbers are valid. I had to comment that out to get my build working, is that because I didn’t import my disk using the importDisk.py script? If so, I’ll just re-import the disk using that script and everything should be peachy. I was curious how that piece of functionality worked (Where does it get the build # from, etc). I’m going to be rebuilding all the images our University uses, so I’ll update my current setup to the latest SVN before I do that and give feedback.

Thanks,

Nate

[Allister Banks]

Hey Nate,

I think what Karl’s doing with making sure people are using reference builds is probably more responsible than having them find out that using a hardware-specific build causes complications on other models. I’d think customizing your catalog file is what you’d want to do anyway once you’re done kicking the tires, it just requires more helpful feedback and documentation, both of which I’ll be providing pronto.
Do you want to make a generic firstboot package, with across-the-board things like time zone and other launchd-called scripting?

Hey Karl,

I think all these tests are genius(who would’ve thought or implemented the restoreProfiler? great work, love where its going), and really am chomping at the bit to contribute in every way. I’ll have a revised guide to you soon.
Could we add Greg Neagle’s payload-free package to Add-Ons? I already contacted him and got approval to point to his blog post for documentation. I’m also going to contribute a package (and an article) here on AFP548 to setup localMCX in the non-default node, just need to run more tests and clean up the text.
I also have revised (10.5 minimum) createUser (with ARD on, optionally, the right way) which dovetails into the above package by creating mcxadmin with the same admin password, just a bit more testing for that as well. I think it’ll really drive home the point about best practices for management and, with Nate’s work on firstboot/launchd, how to finish the rest of the common customizations. What do you think, could it find a home in the project? This is probably a better discussion for the mailing list, but I haven’t got a lot of traction there in the past. Thanks,

Allister

[dead2sin]

I understand what he is doing with Reference builds, I was just curious where it was getting that info from. I am using a Reference build, yet it failed on it me (hence commenting out that line). I wanted to make sure my Mac OS X Install DVD.dmg was ripped in a way that would play nicely with InstaDMG without having to comment out that build line.

As far as the firstboot package goes, I think it would be feasible to make a very generic one that people could use, but we’d have to agree upon what format we want it to be in (pmdoc, iceberg project, etc). I think pmdoc makes the most sense though. I would be willing to go over the one I’ve made already and try to make one that would be acceptable for general use. (com.afp548.firstboot I think would be appropriate).

Nate

[larkost]

I got my list from MacTracker… not exactly the most comprehensive place, but it is what I had available while coding (and everything I had at home fit that list). If you have a reference disc (not a grey one), and can tell me the source for it, and the build number I will probably add it to the list on the vanilla catalog file. The information that I am reading out is in:

/System/Library/CoreServices/SystemVersion.plist

and I also glance over at

/System/Library/CoreServices/ServerVersion.plist

One of the changes that I have planned for 1.7 will change the conversation a bit with regards to how to package scripts. I am going to further relax the “everything has to be a package” idea, but I think I can do so in a way that will make it easy to also re-use things in packages if you want to also use the same tools in places like DeployStudio or Munki.

And stand by, there will be a big announcement at MacSysAdmin, and I am hoping to have 1.7 done in time for MacTech. So if you are going to be at either of those, I should have some things to show you.

[dead2sin]

Sounds great! Can’t wait to hear what you have to announce. I am unable to go to any of the conferences this year, so hopefully I’ll heard about it on afp548 🙂

Nate

[Allister Banks]

Yeah, we couldn’t fit it in the budget for MacSysAdmin, I knew I should have pawned off my MacBookAir!

And reference builds, definitively:
http://support.apple.com/kb/HT1633
Grey discs, definitively:
http://support.apple.com/kb/HT1159

Allister

[larkost]

[QUOTE][u]Quote by: Allister[/u][p]And reference builds, definitively:
http://support.apple.com/kb/HT1633
Grey discs, definitively:
http://support.apple.com/kb/HT1159%5B/p%5D%5B/QUOTE%5D

Unfortunately I am not sure that that is a list of reference releases. Apple usually only has a couple of reference releases per major version. I think that this is a list of versions that Software Update will get you to. The list for 10.5 looks more like reference releases.

[Author]

Posts