Date: Tue, 17 Jan 2012 12:51:51 -0800 From: Devin Teske <devin.teske@fisglobal.com> To: "'Ron McDowell'" <rcm@fuzzwad.org>, <freebsd-sysinstall@freebsd.org> Subject: RE: My thoughts on "bsdconfig" Message-ID: <039201ccd559$d77e0e30$867a2a90$@fisglobal.com> In-Reply-To: <4F15C86B.5020802@fuzzwad.org> References: <4F1361C9.4080403@fuzzwad.org> <4F15C86B.5020802@fuzzwad.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Initial thoughts and comments inline below. > -----Original Message----- > From: owner-freebsd-sysinstall@freebsd.org [mailto:owner-freebsd- > sysinstall@freebsd.org] On Behalf Of Ron McDowell > Sent: Tuesday, January 17, 2012 11:14 AM > To: freebsd-sysinstall@freebsd.org > Subject: My thoughts on "bsdconfig" > > Sent to the wrong list the other day... :-/ > > -------- Original Message -------- > Subject: My thoughts on "bsdconfig" > Date: Sun, 15 Jan 2012 17:31:21 -0600 > From: Ron McDowell <rcm@fuzzwad.org> > To: freebsd-current <freebsd-current@freebsd.org> > > > > I've had some time to poke around dialog, bsdinstall, host-config by Devin Teske, > even old sysinstall. Part of that poking involved a simple proof-of-concept that > can be found at http://fuzzwad.org/bsdconfig/ : > > # tar tzvf /tmp/bsdconfig.120115.tgz > -rwxr-xr-x 0 root wheel 5631 Jan 14 12:53 usr/sbin/bsdconfig > drwxr-xr-x 0 root wheel 0 Jan 12 12:53 > usr/share/examples/bsdconfig/ > -rw-r--r-- 0 root wheel 1553 Jan 14 11:56 > usr/share/examples/bsdconfig/bsdconfigrc > drwxr-xr-x 0 root wheel 0 Jan 14 12:08 usr/libexec/bsdconfig/ > -rwxr-xr-x 0 root wheel 1674 Jan 14 12:17 > usr/libexec/bsdconfig/notimplemented > Nice hierarchy framework. I was discussing with several persons at last week's Bay Area FreeBSD User's Group (BAFUG) meeting at the Hacker Dojo, that I envision taking host-setup and modularizing it in a similar fashion. However, I feel that a better approach would be to allow /usr/libexec/bsdconfig to function more like /etc/rc.d -- specifically that simply installing a new '*.rc' file into said-directory is enough to get a new menu item to appear. The specifics of which I open to discussion, however I envision the main bsdconfig script doing the following on start-up to accommodate a modular architecture of the root (main) menu: 1. Look in /usr/libexec/bsdconfig for '*.rc' (or some similar naming convention). 2. Source each one in the following manner: 2.a. first, syntax-check the rc file using "sh -n FILE". If this fails, warn and skip 2.b. next, source the rc file using "." built-in safely from within sub-shell. If this fails, warn and skip. 2.c. The rc file conditionally provides in some manner (like name= in rc.d scripts) details on how to represent the menu item for this module 3. bsdconfig uses said details to construct the menu-item for each individual module 4. bsdconfig presents the menu 5. When a menu item is selected, invoke the appropriate function within the selected module It makes expanding the tool quite easy as (conceivably) there would be a template for creating new modules (just as there is a template for creating new rc.d scripts). > then several items in the bsdconfig menu [install docs, user add, root passwd, > timezone] execute the code from bsdinstall. This menu was taken directly from > sysinstall and will change somewhat. > I think a better approach would be to have bsdinstall call bits of bsdconfig. If a move is made toward modular-ness, then bsdinstall could directly re-use the modules in /usr/libexec/bsdconfig. This would produce a mode unified set of tools, minimizing code-duplication or unnecessary utility dependency between the two: bsdconfig and bsdinstall. > I'm leaning towards using this above as a base, and then merging sections from > host-config [with Devin's permission, of course] where it makes sense, You of course have my permission (host-setup is of course BSD licensed). However, I think that we can produce something much greater if we work together to produce bsdconfig. > as well as > using existing bsdinstall sections where it makes sense, and adding my own as- > yet-unwritten code for the rest. > In my honest opinion, you'll want to merge from host-setup whenever you can and only fall back to taking bsdinstall code when there's no alternative. I've looked at the bsdinstall code and it isn't nearly as robust in the areas where overlap occurs. For example, in setting the hostname, bsdinstall does not validate that the user input is RFC-952/RFC-1123 compliant while host-setup does. End-result is that a user can end up producing an un-bootable system (bsdinstall always writes the new hostname to rc.conf(5) regardless of input-value). ASIDE: bsdinstall also lacks intelligent management of rc.conf(5) For another example, bsdinstall does not validate network IP addresses entered. Nor does it warn you if you are about to do something that may hang the box network-wise or get you disconnected. I could go on. > Also...what are everyone's thoughts on making this program i18n-ready right > from the start? Lot of work? Not worth the effort? Must have? > Don't need? > I'd say that there's a need to make it i18n-ready. The amount of work (should you start with host-setup) is minimal as I've made sure to use i18n-compatible character-class regular-expressions (e.g. "[[:alpha:]]" instead of "[a-zA-Z]" where applicable). Aside from that, i18n-support should be only be hampered by actual translation services needed to translate dialog content/prompts. -- Devin _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?039201ccd559$d77e0e30$867a2a90$>