Development

Purpose of this page...

Ok, we are going to try to document what is going on.  So this page is going to look kinda messy because the plan is kinda messy.  I'm just throwing up notes that are scattered all over the place.

Name Change

Synadmin is out.

Xhooks is in and refers to the parts that launch start, login, logout, and nightly hooks.  It will include modules such as the setDisplay hooks and tool and such.

Entman will stick around, but only refer to radmind stuff.

Post Radmind

I'm not sure what to call this.  Right now, (2007.05.10) it is called postm_setup.pl.

Goal: get rid of radmind overloads that manage configuration by replacing it with comments in the command file.  For example, this comment will set the resolution, depth, and hertz of a computer:

# DISPLAY = 1440 900 32 60

The above example currently works in the version that SCL has (but not published as of 2007.05.10).  We also can currently set the default homepage for the machine, manage a few files such as /etc/hostconfig and /etc/crontab and a few more things.

We are looking at adding more.  We've started some code that just plain will perform any regex operation on any file (so we can modify anything within the command file) and also a script that will modify plist files (superDefaults.pl).  So from within the radmind command file (or a kink) you can specify a file, a line number or line range, and a regex s/// to perform on it.  This isn't implemented yet, but is very close.

Examples of files/config options we would like to edit from a command file:

web browser tab browsing
key repeat
/etc/authorization
/etc/sshd_config
users and groups
set browser window size
power management prefs (auto power on time)
kerberos (I honestly don't know why this is here, I forgot after I wrote it down)

Another feature is to uncomment and move files.  That means we can deploy plist files as a commented out command file.  Why would we do this?  Because it allows us to edit a plist file in the radmind command folder rather than editing an overload and then having to update a transcript.

Another idea with the plist files is to actually deploy a partial plist and merge it with another plist file.

Why trigger files suck

I've used used trigger files in the past to configure the client machines.  Trigger files are really easy for this because you just create an overload with an empty file with a unique name and put that overload on computers that you want to configure. Then you write scripts that detect if the trigger file is there.  You put the scripts on all of your computers, and thus you don't need unique scripts.  They just behave differently depending on what trigger files are present.

However, over the years, I've discovered a major drawback to trigger files.  The failing point is when you have a whole bunch of nearly identical computers, except for ONE computer that just needs one configuration change.  I use Radmind's command file in command file (kink) functionality to deploy global files including trigger files.  In this setup, I can't just remove the trigger file on that one computer.  I could create a minus overload for that file, but that is ridiculously complex.  I'd rather just move the trigger file out of the global kink into each machines command file.  And that is what I've done.  It is debatable what sucks worse.

Anyway, I haven't implemented it yet, but a better idea that trigger files is to put the comments in the radmind command file (or kinks) and then have the ability to turn them on or off.  So all machines of type x get something like AUTHENTICATED=YES.  Then in stupid machine of type x that for some crazy reason needs authentication turned off, instead of moving the AUTHENTICATED out of the kink, I just put AUTHENTICATED=NO in stupid machine's command file *below* the kink that sets it to yes.  I use precedence just like Radmind does to decide which variable to use.

Problem solved. 

Xhooks links

Duh.  Command files create links so simply.  And we were already using links to "activate" scripts.  So we just moved all the links to a command file and can activate or deactivate scripts by simply editing a command file.  Example:

l ./private/etc/entman/conf/hooks/LID_delete_files.pl ../../lib/secure/LID_delete_files.pl
l ./private/etc/entman/conf/hooks/LID_empty_folders.pl ../../lib/secure/LID_empty_folders.pl

Those 2 lines effectively "activate" those 2 scripts.

periodic scripts

We  disable the periodic scripts on our boxes and instead we run the scripts with post_maintenance.  We need to add smarts to nightly to do it.  Maybe keep track of when it was last done and if too long has passed, run it.

Local homepage w/ refresh

This isn't really an Entman/Xhooks thing.  But the idea is to have a local homepage that refreshes to the default homepage.  This might decrease the slow launch time associated with web browsers on our managed boxes.

Current testing (2007.05.10)

Here is a list of changes since March 6th.

entman_config.pl
- test getTimeStamp

Idlescript - adds date to image

changeip.pl
PMD_create_nightly_launchd.pl
PMD_replicate.pl
postm_setup.pl

set_ip.pl

postm_setup -- need to finish implementing the move list "Uncomment and move to"
I think this script is broke! (2007.05.10)

Ignore permissions on extra hard disks...

Add a trigger file to extra hard drives (Radmind Ignores) that determine if permissions should be ignored.  Or make a list or something configurable rather than ignore them all.

Radmind Certs

Uhh....  Need to handle the certs on the shadow server.  Add -w 2 to download_overload.pl and make sure it works.

History of old changes. In no particular order (who is keeping track???)

- Added a trash so that it doesn't delete files at once, but with the idle script.

Improve relication/shadowed disk images

So the home folder has 10 or so copies and at login one of the copies is moved from the "cache" and chown'ed and used for the active user.

However, there are many other world writable files and such that are dittoed at login.  They are small, so it hasn't been a problem.  But because of this, we have resorted to using a disk image that is mounted as a shadow writable file system for anything that is large.

Ideally, we should improve replication so that it will handle any location, not just the home folder.

And then we should also add support so that disk images are always shadow mounted at login (but not shown on the desktop).  We could even mount them where they really belong (/Applications/StupidApp).  If we automated this, it would make many apps (VPC, Parallels) a lot easier.

LaunchServers

Gee.  It is broke.  Fix it?

- /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/
    LaunchServices.framework/Versions/Current/Support/lsregister -kill -r -domain system -domain local -domain use
    See CLIXchange emails.

Redo cupslib

Ok, this has nothing to do with Entman.  I'm just putting it here because this is like a year old and when am I going to do it?...  Maybe I could include my custom cupslib with Entman...   Anyway, this currently prevents me from putting internet kiosks on an Intel machine.

Possible improvements to create_overload

Print out summary of stuff in:
/Library/Preferences/

Add ./Library/Preferences/com.apple.loginwindow.plist to filter

Portable/Network Home Support

Make it so that if the user's home folder isn't the assimilated home folder that no home management is done.

/Library/Preferences/com.apple.loginwindow.plist

Mounted disk images wont work because they are set to /Users/Authenticated User...

diff com.apple.AutoWake{,2}.plist

I don't know why I'm saving this.  I'm pretty sure there was a good reason.

/Library/Preferences/SystemConfiguration] root# diff com.apple.AutoWake{,2}.plist
5,13d4
<       <key>RepeatingPowerOn</key>
<       <dict>
<               <key>eventtype</key>
<               <string>wakepoweron</string>
<               <key>time</key>
<               <integer>0</integer>
<               <key>weekdays</key>
<               <integer>127</integer>
<       </dict>
17,26c8
<       <array>
<               <dict>
<                       <key>eventtype</key>
<                       <string>wakepoweron</string>
<                       <key>scheduledby</key>
<                       <string>Repeating</string>
<                       <key>time</key>
<                       <date>2007-03-20T06:00:00Z</date>
<               </dict>
<       </array>
---
>       <array/>
28,37c10
<       <array>
<               <dict>
<                       <key>eventtype</key>
<                       <string>wakepoweron</string>
<                       <key>scheduledby</key>
<                       <string>Repeating</string>
<                       <key>time</key>
<                       <date>2007-03-20T06:00:00Z</date>
<               </dict>
<       </array>
---
>       <array/>

What happens when machine is force restarted when PM* scripts are running?

Good question.  I think I fixed this so that it will run again.