Ok have pushed some commits which externalize the configuration file using ConfigParser. Also added a few new commands for handling locales.
IPs are no longer hard-coded and the code was tested on Debian 6 so far (some known issues on Ubuntu). Will add compatibility for other distros. Prateek On 20-Apr-2012, at 2:33 PM, Jan Vlčinský (TamTam Research) wrote: > Hi Prateek. > It was clear, I shall edit the config parameters inside the code. You read my > call properly, extarnalizing config form the code would allow to work on > updating the code and then deploying it somewhere, where is already some > deployment with older version. The most changing part (config) would be well > separated from your code. > > Personaly, I do not like INI files, as they are quite constraining the > structures, which can be placed there. Level of nesting is limited and this > is what I found most problematic. With structures like json, yaml, pickle or > even plain python code the level of nesting and often offer of supported > types is much better. And yaml seems to be the easiest option from editing > point of view. > On the other hand, using INI format is sort of standard, if it solves your > scenarios, then it is valid option. > Please, take it as my personal oppinion, any other view to this topic can be > very valid too. > > About place to discuss the topic - It was simple question. I guess (others > may comment), that initial discussion could take place here, but as soon as > it turns into discussion about separate project/product, then others may > object and new place dedicated to this project may be better fit. I am fine > with discussing it now here. > > With best regards (and thanks for your effort) > > Jan > > Ing. Jan Vlčinský > TamTam Research s.r.o. > Slunečnicová 338/3, 734 01 Karviná Ráj, Czech Republic > tel: +420-597 602 024; mob: +420-608 979 040 > skype: janvlcinsky; GoogleTalk: [email protected] > http://cz.linkedin.com/in/vlcinsky > > > On 19 April 2012 21:00, Prateek Sureka <[email protected]> wrote: > Hi Jan, > > In the original design, config.py is supposed to be user editable (kind of > like fabricrc). Granted that the current design and documentation doesn't > make that obvious - your call for an externalized configuration is valid in > any case. > > I think we can use ConfigParser instead of YAML. Its sufficient for our needs > and part of the standard library and there really is no syntax to learn. > I'll push some code over the weekend (been really busy at work) once I get > our test infrastructure up and running. > > Please advise where we can take this discussion if this group is not the > right place. > > Prateek > > On 18-Apr-2012, at 2:24 AM, Jan Vlčinský (TamTam Research) wrote: > >> Hi >> I like it. >> While testing it (briefly), obviously many tests failed, as IPs etc. are >> hardcoded and there are some assumptions done (like minimal set of service >> and tools already present at machines). >> In past I created set of fab tools for my own use, structured it to tree of >> service names to care about and found, it would be practical to externalize >> configuration parameters from the code. >> So I decided to use yaml configuration format (unfortunately this adds one >> more dependency, but e.g. Google App Engine did exactly the same decission >> and I understand, why is this well readable format preferred). >> >> Just an idea. >> >> Question: is this list the best place for ongoing discussion about this? >> >> Jan >> >> Ing. Jan Vlčinský >> TamTam Research s.r.o. >> Slunečnicová 338/3, 734 01 Karviná Ráj, Czech Republic >> tel: +420-597 602 024; mob: +420-608 979 040 >> skype: janvlcinsky; GoogleTalk: [email protected] >> http://cz.linkedin.com/in/vlcinsky >> >> >> On 15 April 2012 22:01, Prateek Sureka <[email protected]> wrote: >> Hi all, >> >> I've been working on a small set of recipes based on fabric. I use them to >> manage my organization's network of debian/ubuntu hosts. >> >> The key objectives of the project are: >> >> * Easy to use (no installation, little to no dependencies - except >> Python+fabric) >> * Idempotency >> >> The recipes currently available are: >> >> * apt - ensure a package is installed/removed on all hosts >> * cups_client - ensure all hosts are pointing to a specified cups server >> * hosts - ensure the hostname of each host is set correctly >> * lsof - query the open ports on all hosts >> * ntp_client - ensure that the clock on all hosts are sync'd to a central >> time server and timezone is set correctly >> * service - ensure that a particular service is running/stopped/restarted on >> all hosts >> * snmp - ensure that all hosts are set up for snmp using the same community >> string >> * syslog_client - ensure that all hosts are reporting syslog to a >> centralized syslog server (works great with splunk!) >> * web - ensure that an nginx based webserver is correctly proxying a set of >> internal sites (e.g. webmin/cups server/phpmyadmin) using sub-domains >> * webmin - ensure that webmin is correctly deployed on each host >> * whois - use your firewall's arp cache and iptraf mac to hostname database >> to resolve ip addresses and mac addresses to hostname - useful on a DHCP >> network. >> >> For now it only works on Debian/Ubuntu but I plan to (with your help) >> support other flavors of *nix, OSX and Windows as well. >> >> Wishlist: >> * Ability to remotely run anti-virus scans and quarantine infected hosts >> using mac address filtering on the firewall >> * Automatically configure new hosts on the ldap server (user account as well >> as asset record) including pam_ldap authentication. >> * Automount home directories (add a folder with links to commonly used >> applications e.g. intranet/crm/hrm >> * Automatically backup (ensure certain folders are backed up) to offsite >> host. >> * Any more you can think of? >> >> You can find it at: >> https://github.com/surekap/fabric-recipes >> >> >> -- >> Prateek Sureka >> [email protected] >> >> >> _______________________________________________ >> Fab-user mailing list >> [email protected] >> https://lists.nongnu.org/mailman/listinfo/fab-user >> >> > >
_______________________________________________ Fab-user mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/fab-user
