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. Cheers!
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev
