English| Deutsch
› Overview › Process and Use › Requirements › Download › Installation › Configuration » FAQ › News › Feedback › Links
ANI at Sourceforge
SourceForge.net Logo
Commercial Support by
Substring.ch Logo
Valid XHTML 1.0!

FAQ - Frequently Asked Questions

This page tries to answer some frequently asked questions about ANI.

^ top

A - Comparison between ANI and Unattended

On the 9th of august 2004, the wide-spread german computermagazine c't released in their issue 17/04 on page 188 the article "Windows unbeaufsichtigt übers LAN installieren" in which the open source project Unattended is presented.
Because this project has similar goals as ANI and also similar approaches to achieve them, and Unattended was so friendly to put a link to ANI on their homepage ("our friendly competition"), a lot of people come to this website and ask themselves: what are the differences between ANI and Unattended? And why are there two projects? We hope to answer with the following mail exchange.

The two questions were asked on 11th of august 2004 on the ANI-Mailinglist, our answer has also been cross-posted to Unattended. The relevant part of the mail exchange between ANI and Unattended is shown here slightly shortened:

A.1 - Why two open source Projects with similar Goals?

Hagen Münch (ANI) wrote:

OK, please, Unattended people, correct me, if I'm wrong in some places:

First of all, ANI's concept was done and it was nearly completly coded
before we noticed, that Unattended exists as a project at sf.

Therefore we had contact with Unattended, asking about their interest in
the idea to have a linux-bootdisk instead of their DOS-based bootdisk and
get the parameters from DHCP. They said, yeah, why not, send us code. We
were then developing/straightening out all the ANI source code but in the
meantime, they went for the idea (linux-bootdisk) as well. What we had in
the end were two closed coded concepts with a different approach. Merging
seemed to be a crucial test for both projects and hard to realize.

The central idea of the ANI project was to achieve a low-maintance
unattended installation for big Networks and the aim was to provide a
workstation completely fit for service.

The basics of the concept are:
- as less user interaction as possible
- exclusive central maintenance
- (nearly) maintenance-free bootmedia
- only one bootmedia for all and every time :)
- remote installation ability
- fully rollout and migration able

A.2 - What are the Differences between the Projects ANI and Unattended?


|> Hagen Münch (ANI) wrote:
|> The slight diffrences between the projects are:
|> - ANI supports user supports user defined DHCP options to pass basic 
|> options (that results in a maintenance-free bootmedia) and DHCP-
|> Userclasses, usefull to serve different client- or domain-types 
|> even in the same subnet.
| Patrick J. LoPresti (Unattended) wrote:
| What do you mean by DHCP Userclasses?  Our boot disk sends
| "Unattended" as the DHCP user class option (DHCP code 77, defined
| by http://www.faqs.org/rfcs/rfc3004.html), which allows the DHCP
| server to distinguish our boot disk's leases from other leases.

Hagen Münch (ANI) wrote:
That is exact what I meant. We use DHCP user classes e.g to allow
clients to  join different domain types even in the same subnet. Hence
we can use the same DHCP options for different client types.

|> - The linux-bootmedia can be PXE, CD-Rom or floppy disk. We put a
|> lot of effort into getting samba and linux so small that it fits
|> a floppy disk. Unattended has NO floppy disk support, because
|> they use a "normal sized" linux as base. We need floppy disk
|> support because of older hardware not having CD-Rom (deliberetly)
|> and no PXE-capable-NIc.
| I have a plan for supporting floppy boot, although it would require
| multiple floppies.  I am not sure I will ever implement it,
| though. The set of machines which lack support for CD-ROM, network,
| and USB boot is small and shrinking.  And older hardware tends to
| work OK with our DOS boot disk.
You're right. In future the floppy disk support will play a vanishing

|> - ANI installs a so called hidden Maintenance- (with Windows
|> installation files) and an installation media partition on the HD
|> drive. Unattended has not. These partition allows us to trigger
|> reinstallation of windows without access to the net and to do
|> mass-reinstallation/upgrades of computers without having to
|> download all files for each computer again, but instead only the
|> few changed files are downloaded (important to reduce traffic).
|> These partitions even allow us to reinstall/upgrade the OS
|> remotely and centralised with scripts over night, as long as the
|> computer's NIC supports Wake-On-Lan. Unattended needs the
|> presence of a person at the computer to reinstall the OS.
| Some of our users have made fully unattended installations work.
| But you are correct that we do not contemplate it "out of the box".
|> - ANI provides integration abitlities of existing user and user
|> group concepts (unattended?).
| I do not know what this means.  Could you elaborate?

It's no big fead: in the post windows installation of ANI you have the
possibillity to add local users and groups and fill local groups with
other users or domain groups after the join2domain procedure. It may
be configured in a central configuration file (winset.tpl, have a look
at http://ani.sourceforge.net/configuration.php?lang=en#PostWindows
section c.1.12 and c.1.13). It's very simple, but you have nearly
every freedom to integrate existing group concepts.

|> - ANI has a nice UI in case of errors, warnings :-)
| Um, uh, we print a diagnostic and "Abort/Retry/Ignore" :-).


|> - ANI considers some security aspects, wich are desirable
|> especially in big networks: -- We have encrypted passwords for
|> the account to mount the install share and join the domain with
|> the computer. The password is NEVER stored on the client side,
|> either in encrypted or decrypted form. Unattended stores the
|> password on the client side.
| True, but we delete it when we are done.
| I have never understood encrypting a password such that it can be
| decrypted automatically.  If the machine can decrypt it, so can the
| user; isn't that just giving a false sense of security?  Either
| you make a technician type the password when it is needed, or the
| password is available anonymously over the network.  In "real
| security" terms, there is nothing in between.

We use binaries which are only temporarily available to decrypt the
password. Strictly speaking you're right.
But it's a part of ANI's concept: In the case of an interupt of an
installation, everybody has the possibility to get some passwords in
plain text: the local administrators password,  the password to
connect the installation shares and in the worst case the passwort of
a user with account operator rights in the domain (join2domain procedure).
Therefore we decrypt passwords and encrypt them only with temporarily
available binaries. Hence it's very hard for normal users get access
to the passwords.

|> -- We have the abbillity to lock CD-Rom and floppy disk access
|> and other devices depending on the group the loged on user is
|> part of. Unattended has not.
| Can you elaborate?  Are you talking about after the machine is
| installed?

Yes. It's a part of the post windows installation. It works in
combination with the user/group feature mentioned above. We wrote a
tool which writes ACLs on DOS-Devices. Because windows overwrites them
at every system start, we established this tool as a start-up script
as a standard procedure in ANI. Furthermore we have another tool to
de-/activate devices of the device manager (now windows offers
devcon.exe with the same and more capabilities). In combination with a
service, written in perl, you can restrict the access on devices to
certain users and groups.

| I have not used ANI, so I am not sure what features (if any)
| Unattended has which ANI lacks.  Since you managed to fit
| everything on a single floppy, I would suspect our hardware support
| is broader, especially for mass-storage controllers
| (S-ATA/SCSI/RAID).  And I suspect we have better support for
| customized partitioning schemes.

Thats right. ANI is restricted on standards. ANI wants to provide an
environment for standard client concepts. SCSI and RAID is no standard
for common workplaces and normally it's not desirable for an
administator to have a colored machinery. You're completely right
with  your estimation, that the difference is in philosophy. That's
why I meant, that it would be a crutial test to merge both projects.

| But really, the biggest difference is in philosophy. In some ways,
| Unattended is more like a framework for creating a deployment
| system than an actual deployment system.  Our default configuration
| is extremely basic.  But the potential is endless, since you can
| provide custom Perl code which runs before the installation even
| starts.  So you could choose an OU based on the machine name, or
| you could set the host name by looking up its Dell service tag in a
| MySQL database.  All it takes is the right code, and our community
| is experimenting with and sharing all sorts of ideas.
| ANI is a deployment system.  It is less flexible but much, much
| more polished.

I take this as a compliment.

| Actually, "flexible" vs. "polished" is a decent summary of the
| differences.

It's distinguishly summarized, althhough I think, that ANI is extreme
flexible, but in another manner. It's more specialized on certain needs.