FYI:
The Entman suite of scripts/tools, apps is available here which
offers this functionality. If you want to contribute let us know.
http://www.macos.utah.edu/documentation/system_deployment/entman.html
Also, here is a recent email sent to the list...
> Ok, here are some changes and plan for the future. And a little bit
> of the philosophical documentation I've been meaning to write since
> before WWDC2006.
>
> First, we had a request to change the name. We liked Entman, but
> aren't too set on it. It does mean some other things, so what the
> heck, we like to run with scissors, so we'll try a name change one
> more time (we never did fully get away from ULabmin....).
>
> And the new name is.... synadmin, short for synchronized
> administration. The meaning might not be completely obvious, but it
> does make sense. See below. And if you say synadmin real fast it
> will taste yummy!
>
> Second, we are in the process of changing the name on sourceforge
> (yes, we are going to give that another try) but wait until 10.5
> before we actually start changing everything.
>
> Third, I have several co-workers who are contributing for the first
> time. So it isn't just me anymore writing code anymore. So you are
> going to see some other stuff start appearing, like a script that
> will automatically run radmind on a disk in /Volumes and create a
> disk image and upload it so it can be used with ASR. Or something.
> Anyway, good stuff.
>
> Other changes. So a name change means renaming the folder for
> starters! And if I'm going to do that, I would like to move it where
> I think it really should be:
>
> /usr/local/
>
> so I'm thinking
>
> /usr/local/synadmin
>
> or because we hate typing
>
> /usr/local/syna
>
> or something.
>
> Ok, so philosophy. I'm pretty happy with the current philosophy,
> which is, synadmin inserts itself into several OS events, such as
> startup, login, logout, etc and allows you (administrator) to do
> things at those times. But login/out hooks/startup items etc are old
> news. The real gem of synadmin I believe is the idea of modules.
> I'm not sure if it is quite clear yet that this is what I've been
> moving to (starting with entman). But basically, each module can
> insert itself into the OS events and not be dependent on other
> modules. For example, if you only wanted to use synadmin for
> radmind, you would only enable the radmind scripts.
>
> Right now enabling a module means creating a link in /etc/entman/conf/
> hooks that points to the scripts you want run. The names of the links
> follow a naming scheme that indicates when it will run (logout,
> login, etc). To disable a script, you just remove the link.
>
> So what does this have to do with plans? I don't know. First, I'm
> going to try to make the configuration script less big by pulling out
> config items that belong to modules. Before I started to use
> "symlink enabling", the config file included settings that turned on
> scripts. It was huge and complex and very bad. I started to move
> away from that but didn't finish. To finish, I need to pull the
> config file into little pieces. That is, radmind configuration goes
> in a radmind file only. Any script that wants to know anything about
> radmind reads that file. So there will be more config files, but it
> should be easier to find what you can configure. And hopefully in
> the process I remove old settings that aren't even used anymore.
>
> Ok, more plans. So I have started experimenting with the idea of
> getting rid of configuration trigger files. Basically, synadmin is a
> scaffolding and exoskeleton for Radmind. It runs Radmind
> (scaffolding) but more than that, it strengthens Radmind and helps it
> do things it can't alone. For example, the whole idea of trigger
> files was that overloads of empty files ("trigger files") are very
> easy to create in Radmind. Well, with Radmind going case
> insensitive, we ran into the issue of "how do you tell radmind to be
> case insensitive once you make the BIG SWITCH"? Adding a trigger
> file was more work than we wanted. A step that just seemed too
> obnoxious. The answer was to specify the case in the command file
> itself!
>
> One thing lead to another, and it became obvious that TONS of
> settings ("trigger files") have a one to one relationship with a
> command file. For example, lab machines had a lab command file.
> Well, instead of having an overload for a "lab" trigger file (the
> current method), why not just read the command file and find out what
> is in it? In fact, why not just include the information to be read
> in commented lines in the command file? And then the next step was
> to move a whole config file, radmind_reboot (the file that determines
> what IP's run radmind when) into the command folder, add a comment #
> to every line, and then have the script that reads it uncomment one
> #, and then read that as if it were the original format.
>
> In other words, no more overloads of configs. If you want to change
> a config, like the resolution of a machine, you go to that machine's
> command file and make the change. Nothing to upload. Nothing to
> checksum. I've set it up but not fully tested it. But the next
> version of Entman should start to have this ability.
>
> So that is the big plan. I've only started to experiment with this
> (partially because I'm really tired of my coworkers updating the
> radmind_reboot config file overload, which is a task that conflicts
> with my development work). I still plan on supporting all of the old
> config methods, but use the command file version first if it exists.
> Please let me know what you think about it as it is a major change.
>
> The final plan I wanted to mention is something I've wanted to do for
> years. It involves config files again. But it also relates to
> language. I've used Perl because that was what I learned mainly
> because the radmind scripts that RSUG provided were in Perl and
> shell, and I found that text editing in shell was a PITA, but easy in
> Perl. So I used Perl. Lately I've grown fond of Ruby. Some other
> people have bugged me to drop Perl in favor of Python. But I just
> can't port the whole thing to any language because that is a lot of
> work that doesn't really need to be done.
>
> However, because of the module approach, the scripts can be in any
> language you want. Except for one thing. The problem is that my
> little shortcut for writing a real config parser was to use library
> files and include them in the scripts. Unix does that with /etc/
> hostconfig so I don't feel too ashamed for doing this. But it makes
> getting away from Perl REALLY HARD because I don't want config files
> of the same settings for multiple langauges.
>
> So my solution is to write a script that runs first thing after
> radmind, and takes *global* language-agnostic config files, parse
> them and save language specific config files (like includes). I have
> done 0 work on this, but because I have some coworkers who aren't
> invested in Perl like I am and instead are using shell and might even
> use Ruby, writing the scripts to do handle global config files is a
> lot more likely to happen soon. There are a lot of other benefits
> besides language agnostic as well, like, no more polling. However,
> it means that to make a change on the fly (on a managed machine), you
> have to change the global config file and then run the script that
> changes everything else. Not too bad of a negative I think.
>
> Let me know what you think about all of this. It will take awhile
> for all of this to happen, so everyone has time to provide input.
> Except I think we are pretty set on the name change. And we are only
> going to have one mail list because there aren't enough users or
> developers using the list to justify 2. But I know you are out
> there, even if you are silent! Anyone ever perform on stage with
> lights shining in your eyes so bright you can't see the audience, but
> you hear coughing, whispers, and one or two catcalls ;) so you know
> someone is out there? That is what providing entman is like for
> us. :)
>
> Anyway. That's all for now. It is snowing outside. And I get to go
> home now! Have a good day!
>
> James
On Oct 27, 2006, at 9:35 AM, Neagle, Greg wrote:
> That's something I really like about my current run_radmind script
> (which has code conceptually from James Reynolds, Ian Ward Comfort,
> and myself) - it keeps the last five applicable transcripts, writes
> a "high-level" log to /var/log/run_radmind.log, and more detail to
> other log files. Whenever I've had a problem, there has usually
> been enough evidence left behind for me to quickly figure it out.
>
> -Greg
>
> On Oct 27, 2006, at 7:02 AM, Jeremy Reichman wrote:
>
>>
>> I also think the tools should be logging some level of information
>> locally,
>> by default. The more detailed, the better, as far as I'm
>> concerned. At the
>> very least, the tools should log the errors that cause a session
>> failure,
>> and perhaps preserve the apply-able loadset for analysis.
>
> ----------------------------------------------------------------------
> ---
> Using Tomcat but need to do more? Need to support web services,
> security?
> Get stuff done quickly with pre-integrated technology to make your
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache
> Geronimo
> http://sel.as-us.falkag.net/sel?
> cmd=lnk&kid=120709&bid=263057&dat=121642______________________________
> _________________
> Radmind-users mailing list
> Radmind-users@...
> https://lists.sourceforge.net/lists/listinfo/radmind-users
Thanks,
Richard Glaser
University of Utah - Student Computing Labs
|