Greetings, On Sun, Apr 5, 2009 at 11:53 AM, Tzafrir Cohen <[email protected]> wrote: > On Thu, Apr 02, 2009 at 10:59:01AM +0300, Tzafrir Cohen wrote: >> Hi list, >> >> I'd like to consult with the members of the list with a small issue I'm >> facing. >> >> We use a DebianLive-based CDROM (current version is based on Etch) to >> provide a testing environment for our customers: We produce a hardware >> that uses the out-of-tree Zaptel/DAHDI drivers, and mainly used by the >> very configurable Asterisk. Our product has its own setup needs. This >> leaves some room for human errors and such on setup. > > A followup with a different part of the problem. > > The live CD / USB runs a an Asterisk server. As it needs to come in > place of existing servers, I don't want to assume a local keyboard and > screen will be required. > > Hence the CD boot automatically (though after some time out). It also > means that I cannot rely on interaction with someone at the console > before allowing the use of services (ssh, web interface for Asterisk). >
I have a live CD setup that pastes information about the boot and if all things are well on the remote end. I just put some basic tests in rc.local then have the unit paste the info back home to me. > For a potential USB version I thought I could somehow default to being > "disabled" and change that if the user sets password through a file on > the USB HDD. Seems simple to implement, though not intuitive enough. Any > better suggestions? What would be a pretty slick way is what I tested over a year ago with giving a customer number and an equipment number to users for them to pull in a hook from the web as a boot param. You could ship out a usb drive with a boot param like hook=http://your.company.org/customer_number/equipment_id/rescue.sh that would phone home to your company web server and all you do is enable the hook when you need it from the server side. It is also a nice way to ensure support is up to date. The down side to the above is that hook= boot param is broke. I have filed a bug for it. > > But as I wrote before, using USB on its own is not intuitive enough, so > I can't rely on it alone. > > And just in case anybody actually considers the "ignore" way out of > this: if the distro is too much of a security risk, there will be enough > customers not willing to use it to test their equipment in the field for > that reason, and we have a support problem again. > > There would be some security risk to the above and any solution, but the hook= model risks can be mitigated in several ways. If interested we can discuss more. I am on the irc often. > So any ideas on what I can do? > There are other ideas than the above but the above seems to be a very good thing if hook= was working. > -- > Tzafrir Cohen > icq#16849755 jabber:[email protected] > +972-50-7952406 mailto:[email protected] > http://www.xorcom.com iax:[email protected]/tzafrir > > > -- > To UNSUBSCRIBE, email to [email protected] > with a subject of "unsubscribe". Trouble? Contact [email protected] > > -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
