- Automatische Netzwerk Installationen - Automatische Netzwerk Installationen
Hier werden häufig gestellt Fragen zu ANI beantwortet.
^ nach oben
Im verbreiteten deutschsprachigen Computermagazin
c't erschien in der
Ausgabe 17/04 vom 9.8.2004 auf Seite 188 der Artikel "Windows
unbeaufsichtigt übers LAN installieren", in welchem das
open-source Projekt
Unattended vorgestellt
wird.
Da dieses Projekt ähnliche Ziele wie ANI hat, diese auch ähnlich
umsetzt und Unattended freundlicherweise einen Link auf ihrer Homepage
auf unsere gesetzt haben ("our friendly competition"), surfen nun viele
Leute hier vorbei und fragen sich, was denn die Unterschiede zwischen
ANI und Unattended sind und warum eigentlich zwei ähnliche Projekte
existieren. Hoffentlich dient der folgende Mailwechsel etwas zur
Klärung.
Die zwei Fragen wurden ursprünglich am 11.8.2004 auf der ANI-Mailingliste gestellt und unsere Antwort auch an Unattended gepostet. Der Einfachheit halber wird hier der relevante Teil des Mailwechsels zwischen ANI und Unattended leicht gekürzt wiedergegeben:
Hagen Münch (ANI) writes: ... 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.