Author: anonym Date: To: The Tails public development discussion list Subject: Re: [Tails-dev] [GSoC] [tails-server] Ideas and challenges about
asking the user's passphrase on boot
04/13/2012 10:55 AM, intrigeri: > Hi,
>
> anonym wrote (12 Apr 2012 13:52:00 GMT) :
>>> tails-server is expected to run on a LAN with a DHCP server (needs
>>> to be added to the specs, btw), so I don't think the user can
>>> ensure this IP is left free for this specific system? Custom static
>>> leases are often not an option.
>
>> Actually, most people I know prefer to use static IP configurations
>> for all servers on their LAN, and some people I know don't use DHCP
>> at all.
>
> Those people use SSH, know about static DHCP leases, and setup port
> forwarding. I don't think they are our target userbase for Tails
> server.
We shouldn't exclude them either.
> Or did I miss an easy way to solve this static addressing problem when
> a DHCP server is running the place?
That's up to the user. Note that I only want static IP configuration to
be supported, not the default.
>>> Given this, I don't see how the static IP way
>>> would be a practical solution. Did I miss anything?
>
>> The only drawback I can see with allowing this is that the static IP
>> configuration would have to be unencrypted and stored separately
>> from the Tails server config some how. Luckily it can easily be
>> achieved specifying it on the kernel cmdline, and having the The
>> Tails server configuration tool modifying the syslinux menu file
>> accordingly. If none is given the default should of course be DHCP.
>
> I think this is already supported by live-boot / live-config.
Ah! Indeed, the `ip` boot parameter does the trick. Thanks live-boot!
> I agree we want to support this case too (seriously lower priority
> IMHO, though).
I could buy the argument that people who uses static IP configurations
likely don't need a GUI tool to set it up for them. We could just
mention the `ip` boot parameter in the docs and suggest that they can
manually edit the syslinux menu file to get it there persistently.
>>>> Using https would of course be nice, but since this implies using
>>>> self-signed certs (right ?), it might scare users.
>>> If you decide to go the HTTP way: I agree self-signed certs, unless
>>> well integrated into the client's persistent configuration, are
>>> a no-go. Such integration is a must.
>
>> Perhaps a "Tails server" persistence preset (stored at
>> ~/.tails-servers) could host these? Any certificates found there
>> would be added to iceweasel on as soon as Tails has opened the
>> persistent volume and found this preset.
>
> Yes. This was exactly what I expected Julien to reply.
:/
>>> This holes do not need to be permanent:
> [...]
>> OTOH, the web server approach allows a ridiculously simple
>> client-side GUI in Tails that starts/stops avahi, and scans and
>> lists Tails servers (and yes, there can be many, so it should be
>> possible to distinguish between them some how). When clicked,
>> iceweasel simply opens the selected server. This should even be
>> doable in fairly small shell script using zenity :).
>
>> I think it still is a pretty nice advantage to be able to unlock the
>> Tails server from any avahi/zeroconf-aware OS compared to just from
>> another Tails instance.
>
> Sure. This was exactly what I expected Julien to reply.
:/
It seems I'm too enthusiastic about solving problems rather than guiding
jvoisin towards the solution. I'm sorry for this. I'll try to shut up more.
