Forum Replies Created

Viewing 15 posts - 1 through 15 (of 33 total)
  • Author
    Posts
  • akinspe
    Participant

    I had a similar problem. I added a /usr/sbin/diskutil repairPermissions “$TARGET_IMAGE_MOUNT” to the build train and it fixed those fontd issues. My rough estimation was that it had to do with the permissions of the /Library and specifically /Library/Caches

    in reply to: createUser NOTICE #376974
    akinspe
    Participant

    [QUOTE][u]Quote by: hetjan[/u][p]I can’t wait. createUser doesn’t currently work on my 10.5.8 buildtrain[/p][/QUOTE]

    This update will not fix that since there are no substantive changes to the code that actually creates the user. Only relaxing the checks to function under 10.6. The problems you are having are likely because of a bad USERDATA file or perhaps something with your InstaDMG setup. Are you using the latest version of instaDMG? I know that some of the chroot stuff that was done required some changes so it would work properly. It was not createUser, but instaDMG that needed to be updated.

    in reply to: 10.5.7 and Console.app #376365
    akinspe
    Participant

    Interestingly, this does NOT happen if you use the more recent InstaDMG builds that utilize the chroot facility to jail the installers. Seems that 10.5.7 combo update is doing some not nice things if it requires that.

    in reply to: Flat packages #376313
    akinspe
    Participant

    I stand corrected. The –flatten parameter only works for folder hierarchies that match what a flat package should be. this will not necessarily work if the package was an existing “non flattened” package. You may need to extract the files and use packagemaker to create a flat package in this case.

    in reply to: ACL’s on Home Directory #376307
    akinspe
    Participant

    [QUOTE][u]Quote by: vogtstev[/u][p]Greetings!

    I’ve recently noticed my home directories that are created via CreateUser have ACL’s associated with them. I can see this in terminal by doing ls -l and noticing the “+” next to all my permissions, which I believe indicated ACL’s are present. So it looks something like: “drwx——+” for the Documents folder.
    If I look at Get Info things seems normal displaying owner (me) with “Read & Write” and everyone with “No Access”

    So I guess my question is, do I have to worry about these ACL’s? I haven’t noticed these a new out of box system so I was unsure.

    Thanks!
    Steve[/p][/QUOTE]

    They are part of a new system you probably just didn’t notice. And since createUser does not create home directories it is not a part of this process anyway.

    -Pete-

    in reply to: Flat packages #376306
    akinspe
    Participant

    /usr/sbin/pkgutil

    Use the –flatten option with your package as a parameter. That’ll do the trick.

    in reply to: createUser password not accepted #374858
    akinspe
    Participant

    [QUOTE]Does this apply to hashes created by the shadowHash script, or just to cleartext passwords entered into the USERDATA file? I has assumed this statement applied only to the USERDATA file. My password has several special characters.[/QUOTE]

    you may need to enclose your password in quotes depending on the characters used. This is not a function of shadowhash, but rather a consequence of the shell interpreting your characters.

    i.e.

    ./shadowHash “yourpassword”>password_hash

    Hope this helps

    in reply to: createUser 1.0.2 #373028
    akinspe
    Participant

    It’s not only intrinsic to InstaDMG, but because of the significant differences in local directory services between Tiger and Leopard it just won’t work. The Tiger branch has to call nicl to do its dirty work and that command is, of course, gone on leopard.

    What’s disappointing is I know of no way to send more descriptive error messages through installer to tell the user WHY it failed. I actually have quite detailed error messages, but you never see them in the instaDMG log because I know of no way to pass that through. Anyone with ideas? All echo statements seem to go to the abyss.

    in reply to: createUser 1.0.1 #372625
    akinspe
    Participant

    [QUOTE][u]Quote by: thisgarryhas2rs[/u][p]I’m having a bit of a problem with the new createuser pkg. I used the first version and it worked great. I downloaded this 1.0.1 version and edited the USERDATA file and ran it in InstaDMG. The log file said it failed to run postflight. I tried tinkering it a bit but no go. I downloaded both version 1 and 1.0.1 and ran it out of the box completely default. Version 1 created the user no problem but 1.0.1 still gave me the “failed to run postflight” even when it was default. I read people said it worked right away. I’m not sure what I’m doing wrong!

    Any help or troubleshooting tips are welcomed.[/p][/QUOTE]

    It is _I_ that need the help. There was a really bonehead typo in the 1.0.1 script that I didn’t catch right away. I’m posting a revised version right away. Sorry!

    in reply to: createUser 1.0.1 #372588
    akinspe
    Participant

    [QUOTE][u]Quote by: thespider[/u][p]I have a question about my password and the shadowhash script, I use a pipe “|” and I know why the script is failing, but if I quote the whole password, will that work? Are there other methods, short of changing my password, to fix the issue? Thanks![/p][/QUOTE]

    I’m not sure I understand the question. But you shouldn’t use a pipe, it should be a greater than “>” i.e.

    /path/to/shadowHash “yourpassword”>password_hash

    And yes quoting it should be fine, but I haven’t done thorough tests on “exotic” passwords. In theory it should work with any ASCII characters.If you’re having trouble with a particular password, let me know. I wouldn’t expect you to tell me the password, but perhaps if there’s some wacky characters there may be an issue. Also when you say the script is failing what do you mean?

    in reply to: createUser 1.0.1 #372587
    akinspe
    Participant

    [quote]do you think createUser.pkg should be able to create more than one user using InstaDMG by running the package twice?[/quote]

    The short answer is YES. There’s no reason that it shouldn’t be able to run twice since all it’s doing is running a bunch of dscl commands. The issues stated above are mostly likely. That either the UID isn’t different, or the GUID isn’t different. presuming you left the UID blank then it should use 501 and 502. I will see if that is indeed the case or if there’s a bug there. I didn’t test that part as throughly, but if coded properly I would expect it to work. Stay tuned…

    akinspe
    Participant

    Admin User
    If you don’t want to use a first boot thing for 10.5, then please try out my createUser.pkg You CAN create a user before first boot on 10.4 by running nicl in raw mode

    ARD:
    I use a Custom ARD Installer made from ARD and it works perfectly. Since the kickstart script is made to work on non-startup volumes (there is a -targetdisk option in kickstart that makes this all work), I’m curious why you it won’t “just work” for some of you? Are you doing something unusual that can’t be applied?

    Enable Root:
    I’m not sure, but I thought it just created a hash for the fixed GUID of the root account (FFFFEEEE-DDDD-CCCC-BBBB-AAAA00000000), so it could in theory be done at creation time. that way you’re not sticking the password in a script. But if there’s more than that I’d like to know.

    TimeZone/ntp
    I actually just drop the /etc/ntp.conf file and alter /etc/hostconfig to enable ntp. creating a symlink from /usr/share/zoneinfo/XX/XXXX to /etc/localtime does it for timezone. i.e.
    ln -s /usr/share/zoneinfo/US/Eastern “$3/etc/localtime” in a postflight script does the job.

    Registration/movie
    there is now a package available to disable the registration/movie

    Directory Services:
    I actually created a package with the appropriate /L/P/DirectoryService/*.plist files for our OD, but then again we don’t do authenticated binds, so that’s no biggie

    SSH:
    You could just remove the disabled flag of /S/L/LaunchDaemons/ssh.plist

    At this point I have very few “FirstBoot” tasks. I wrote a StartupItem that would execute a series of scripts in a known folder and then erase itself. Certainly a launchd item would work as well and probably would be future resistant. The idea is that the master script is generic, but then you can “package” the other scripts as components and they just get installed in the folder. This makes it more modular.

    But very few of these NEED to be FirstBoot.

    in reply to: 1st image made off of a System Restore disk #372279
    akinspe
    Participant

    I was just thinking…

    Another way to handle this would be to allow an option to specifiy the name of the CustomPKG folder at runtime. Also perhaps allowing multiple CustomPKG folders. that way you could have a set of “basic” packages and then folders for your other groups of packages.

    Then a clever person would just have a wrapper script that has the appropriate instadmg parameters in a script so they could chain them together and build all their images in serial. You’d have to have an option to allow the user to change the name/location of the DMG Scratch and resulting ASR image.

    I didn’t get a chance to watch the webcast, so I didn’t see your “roadmap” I suppose it’s possible that you covered that.

    in reply to: 1st image made off of a System Restore disk #372278
    akinspe
    Participant

    The way I handle multiple bulid-trains is making a copy of the instadmg “environment” and have a master folder where ALL my packages are, and then just symlink the appropriate packages into each InstaDMG’s instance CustomPKG folder. That way I can maintain different versions of the image, but not duplicate packages. I also, of course, am symlinking the OS DVD image.

    The client management system could work, but with some packages getting as large as they do, and our lab image approaching 30gb+, that’s not really an efficient option for us.

    akinspe
    Participant

    Well first I think it’s important to define what needs to run on first boot and what does not. For instance. You can make yourself an ARD Client Install package and alleviate any need to do anything manual yourself. Many things can be done prior to booting and therefore don’t require any special launch agents or startupitems.

    Really about the only things that would require that would be:
    a) Things that alter files that aren’t present until the machine first boots
    b) Things that set values based on the exact hardware found
    c) Things that generate unique identities that shouldn’t be duplicated
    d) Packages that don’t work well when they aren’t on the boot volume (hopefully these would be repackaged, if possible)

    Am I missing something?

    Although StartupItems are/may be deprecated, they still have one feature that launchd items don’t: clear dependancies. For example you may have certain items that can’t run until there’s an available network.And let’s face it. They still exist and will continue to exist for another few years even if 10.6 does away with them.

    I had actually created a generic FirstBoot package that ran all scripts/packages in a certain folder and then removed itself afterwards. This was mostly because I have a script that sets the computer name based on the serial number (although WGM will change it if it’s already in the OD, of course), and also I still can’t get KeyAccess to work properly unless it’s run on the same volume. But I’m still looking itno that. And Office 2008 updater is REALLY stupid. The “package” just moves all the stuff into a temp folder and then a bunch of scripts move the files. I’ll probably have to repackage that.

    Anyway. It’s an interesting question. Some standardization might be in order. Perhaps a folder to put packages that need to be installed, and perhaps a folder of scripts that should be run.

Viewing 15 posts - 1 through 15 (of 33 total)