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