Re: cdrom vs usb-hdd
On Sun, Apr 5, 2009 at 11:53 AM, Tzafrir Cohen <firstname.lastname@example.org> 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
>> 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
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@example.com
> +972-50-7952406 mailto:firstname.lastname@example.org
> http://www.xorcom.com iax:email@example.com/tzafrir
> To UNSUBSCRIBE, email to firstname.lastname@example.org
> with a subject of "unsubscribe". Trouble? Contact email@example.com