- Automated Network Installations - Automated Network Installations
This page tries to answer some frequently asked questions about ANI.
^ top
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:
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
... |> 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 role...(r.i.p) |> - 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.