[Tails-dev] Tails Server: Why not just an extensions to Tails Desktop?
https://tails.boum.org/todo/server_edition/#index5h2 Remove unnecessary/irrelevant things from boot process Tails server should not spawn a full-featured desktop anymore: the goal of this iteration is to remove as much irrelevant services as possible (e.g GNOME, Xorg, ...) in order to reduce boot-time and system resources. The only way the user have to do administration’s related tasks is to use SSH. https://tails.boum.org/todo/server_edition/#index9h2 Switch to server mode at boot time [...] I think that is a mistake and violating your design. Your design states you want it as simple as possible, for normal users. SSH-only administration makes it much more difficult. - user needs to learn SSH - user needs two computers instant of one, a Tails Server and a Tails Desktop - Don't you think, a user running Tails Server doesn't wish to fire up a torified browser for a quick search? Maybe people start asking for a mix of Tails Desktop and Tails Server. SSH administration is a nice feature, but shouldn't be the only way for administrative tasks. I recommend to add the server features to the regular version. As a bonus you can simplify the design and get it done faster. That doesn't prevent you from adding a no-autostart-gui or minimalistic-gui feature to Tails. (To satisfy your requirements for compatibility with low RAM.) ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tails Server: Why not just an extensions to Tails Desktop?
Hi, Thank you for these comments! adrelanos wrote (03 Sep 2012 10:23:22 GMT) : SSH-only administration makes it much more difficult. - user needs to learn SSH I have to make it clear that the main configuration interface is a GUI, running in a normal Tails. So, no, the user does not need to learn SSH. SSH access is rather meant for advanced users who, without doubts, will want root access on their server, if only to check from the inside that things are running smoothly. I'm sorry if that part is not clear in the published design. - Don't you think, a user running Tails Server doesn't wish to fire up a torified browser for a quick search? I guess they want. But well, the fact that people might want to run a torified web browser at the same time they run, say, their 24/7 fridge, is no reason to run a web browser within a fridge :) Maybe people start asking for a mix of Tails Desktop and Tails Server. Not that I know of (yet?), but who knows :) SSH administration is a nice feature, but shouldn't be the only way for administrative tasks. Fully agreed. This was not what we had in mind. I recommend to add the server features to the regular version. As a bonus you can simplify the design and get it done faster. I acknowledge doing so might speed up development. On the other hand, raising the hardware requirements seems bound to make it harder to find early testers and adopters, which might slow down development. I guess the ones who will actually put days of work into this project will decide :) That doesn't prevent you from adding a no-autostart-gui or minimalistic-gui feature to Tails. (To satisfy your requirements for compatibility with low RAM.) Well, I think this is a matter of general vision. I think the majority of personal computers sold these days (not including smartphones) are laptops, and are not online 24/7, so not suitable to be servers. So, I still consider the original Tails server vision (using decommissioned computers, that can be plugged anywhere and run 24/7) makes sense. (Incidentally, this means the no-GUI thing is no bonus, but a real basic requirement. While supporting some other kind of no-GUI or light-GUI more general usecase is not something we have considered yet, and clearly not on top of our priorities.) In any case, anyone actually implements Tails server is likely to set their own priorities. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] [tor-talk] Please review Tails stream isolation plans
Hi, Nick Mathewson wrote (30 Aug 2012 15:10:52 GMT) : * Pidgin Not too scary, I think. You'd typically wind up with one destination per chat, or one per chat protocol? Typically, per chat account. * Liferea RSS feed reader This one is a little scary. Do I understand correctly that an RSS reader will make a separate connection for every RSS feed that you subscribe to? If so that might make some pretty serious load. Yes, it will. I've personally been using per-destination separate streams for 70 feeds in my own reader for a while. Shame on me for loading the Tor network, maybe, but at least I can confirm it works well. Anyhow, I don't expect many Tails users to make such an intensive use of the feed reader: RSS in itself is unlikely to grow in popularity, and like it or not, modern uses involve a web-based RSS reader rather than a desktop one... Then you have a few command-line ones such as wget. Also, some software that is not SOCKS aware, such as APT, goes through Polipo (to be replaced with Privoxy, some day). Oh wow. Instead of shunting these applications' traffic through Polipo or privoxy, have you considered relinking against torsocks to *make* applications understand SOCKS, We have not considered adding SOCKS support to APT and wget, and given our limited resources, I doubt we'll do it. We could probably run them using torsocks, though. or using some kind of iptables trickery? I'm not sure how doable it is to use iptables to convert HTTP proxying to SOCKS, but I'd be happy to learn :) When we stopped using those proxies, we weren't really thrilled with their security or their performance. It makes me uncomfortable to see and here goes an HTTP proxy in any Tor design these days. Sure. Instead of investing time to move to Privoxy, we might as well want to simply drop Polipo. I've updated our ticket on this topic accordingly: https://tails.boum.org/todo/replace_polipo_with_privoxy__63__/ Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Upcoming release schedule plan
berta...@ptitcanardnoir.org: Hi, Following our discussions on the timeline for the next release, here is the plan we ended up with and I committed to send on this list : - Theoritically: ESR (August 28th) + 1 week = September 4th - August 23: release 0.13~rc1, do the test suite together - Week 35 - Mon 27th: ESR is out update of the GnuPG docs - Week 36 - Tue 4th: release 0.13~rc2, testing phase At this point we should've had the Iceweasel ESR, but nowadays Mike Hommey seems to only upload to the official backports instead of mozilla.debian.net, so it won't go live until it hits testing (remember, there's a 10 day delay for unstable -- testing). The end result is that we will have the ESR no earlier than the 9th of September (and hopefully no later so we can spend 10-11th running the test suite). Because of this, and that not a single other package has been updated since ~rc1, some of us seemed to think that an ~rc2 would be a waste of time. Looking at the recent changes in the testing branch also supports that: $ git log --abbrev-commit --pretty=oneline 0.13-rc1..testing 6d7395d Import live-config and live-config-sysvinit 3.0.3-1. 406ecac Rewrite the changelog for 0.13~rc1 in a more digest form 2faaa6b Enable the ikiwiki trail plugin for the locally built wiki too. (+ another not-yet pushed commit that updates the deb.tp.o signing key, which expired today) At first glance 6d7395d may look like something, but actually it just makes sure that we pin the versions of live-config* we already shipped in ~rc1. Given all this, unless someone strongly objects, I will skip preparing/uploading/announcing ~rc2 and work on something more productive tomorrow. Cheers! signature.asc Description: OpenPGP digital signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review bugfix/fix_background_readahead
On Sun, Sep 02, 2012 at 02:37:24PM +, Ague Mill wrote:
On Sun, Sep 02, 2012 at 03:28:36PM +0200, intrigeri wrote:
Ague Mill wrote (01 Sep 2012 12:26:51 GMT) :
Can someone else test the changes, now? :)
:)
I'm unlikely to do it any time soon on bare metal,
but it might help it that work was merged into experimental.
Given it's a candidate for 0.13, I think it's not the best branch to
test it, but I've done the merge nonetheless.
I still understand what could it make worse than the current situation,
but given that:
anonym I'd like to see that live in experimental for a while before
I trust it :)
ague Should I write another patch that remove the offending 'cat'
that is not running in the background?
intrigeri I think I would happily merge that one.
See attachment.
--
Ague
From 1c0883518de62c30b1aee8e40e706b39013806ec Mon Sep 17 00:00:00 2001
From: Tails developers amne...@boum.org
Date: Mon, 3 Sep 2012 17:44:09 +
Subject: [PATCH] Stop readahead pretending that it can read file in the background
Files are not read in the background. This means we have a noticable pause
without any progress bar. This just slow the boot process, so let's stop
reading those extra files.
---
.../lib/live/config/-readahead |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/config/chroot_local-includes/lib/live/config/-readahead b/config/chroot_local-includes/lib/live/config/-readahead
index c29edbd..fdaecf9 100755
--- a/config/chroot_local-includes/lib/live/config/-readahead
+++ b/config/chroot_local-includes/lib/live/config/-readahead
@@ -25,21 +25,15 @@ Readahead ()
Start_readahead ()
{
FG_FILES=$(sed -n \:$BACKGROUND_AT:q;p $READAHEAD_LIST)
- BG_FILES=$(sed -n \:$BACKGROUND_AT:,\$p $READAHEAD_LIST)
FG_SIZE=$(
cd /
echo $FG_FILES |
xargs du -c 2/dev/null |
awk '$2 ~ /^total$/ { t = t + $1 } END { print t }')
(cd /
- echo $BG_FILES |
- xargs stat /dev/null 2/dev/null || :)
- (cd /
echo $FG_FILES |
xargs cat 2/dev/null |
pv -f -s ${FG_SIZE}k /dev/null || :)
- (cd /
- echo $BG_FILES | xargs cat /dev/null 21 || :)
# Creating state file
touch /var/lib/live/config/readahead
--
1.7.2.5
pgpZop5bOKjO9.pgp
Description: PGP signature
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review bugfix/fix_background_readahead
On Mon, Sep 03, 2012 at 05:48:10PM +, Ague Mill wrote: On Sun, Sep 02, 2012 at 02:37:24PM +, Ague Mill wrote: On Sun, Sep 02, 2012 at 03:28:36PM +0200, intrigeri wrote: Ague Mill wrote (01 Sep 2012 12:26:51 GMT) : Can someone else test the changes, now? :) :) I'm unlikely to do it any time soon on bare metal, but it might help it that work was merged into experimental. Given it's a candidate for 0.13, I think it's not the best branch to test it, but I've done the merge nonetheless. I still understand what could it make worse than the current situation, ^ don't *sigh* -- Ague pgpzdF0Kd45x8.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] [tor-talk] Please review Tails stream isolation plans
intrigeri: Hi, Nick Mathewson wrote (30 Aug 2012 15:10:52 GMT) : or using some kind of iptables trickery? I'm not sure how doable it is to use iptables to convert HTTP proxying to SOCKS, but I'd be happy to learn :) Iptables can not translate from one protocol to another. The closest thing you could do is using something like redsocks. [1] With iptables you can redirect packages based on their destination IP, destination port, linux user account, and or process/session id. Redsocks accepts them and can forward them to another http or socks proxy. But what's the point? It's a real hack. A clean solution would be to add http proxy support to Tor [2] or to add socks support to the applications. Torsocks can be used as a hack. [1] http://darkk.net.ru/redsocks/ [2] https://trac.torproject.org/projects/tor/ticket/6060 ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] [tor-talk] Please review Tails stream isolation plans
Nick Mathewson: On Sep 3, 2012 2:21 PM, adrelanos adrela...@riseup.net wrote: intrigeri: Hi, Nick Mathewson wrote (30 Aug 2012 15:10:52 GMT) : or using some kind of iptables trickery? I'm not sure how doable it is to use iptables to convert HTTP proxying to SOCKS, but I'd be happy to learn :) Iptables can not translate from one protocol to another. But it can forward connections to a transparent proxy -- like, say, Tor's TransPort feature. The tricky part here would be coming up with a way to forward only the correct connections. I'd certainly help with rule creation, I experimented already with it. The safest thing would be probable to start each application under their own user account, or using other iptables -owner features, perhaps in conjunction with a per destination port. But like said before, I don't think this is a good solution. Failing that, torsocks is indeed a way pretty good option. I don't think so. It's only a hack. Doesn't work on Windows. It can be sufficient for distributions such as Tails or aos. For end users it's much too hard to use torsocks for stream isolation. A clean solution is much desirable. Reasons: It has an IPv6 leak bug. https://trac.torproject.org/projects/tor/wiki/doc/torsocks#WorkaroundforIPv6leakbug A patch flooding all console output (and therefore breaking applications based on console applications) is still not merged upstream. https://code.google.com/p/torsocks/issues/detail?id=3 Fortunately intrigeri merged it into Debian. Torsocks / usewithtor does not support choosing to which Tor SocksPort you want to redirect. We need this to utilize stream isolation. I wrote a hack. https://trac.torproject.org/projects/tor/wiki/doc/torsocks It's far from perfect. Still requires a wrapper. How else people could transparently use apt-get with stream isolation, without issuing torsocks themselves. I mean, without a wrapper they had to use 'torsocks apt-get' instant of a simple 'apt-get'. For more reasons please referrer to my last mail on Tails-dev about this topic. https://mailman.boum.org/pipermail/tails-dev/2012-August/001422.html The relevant part begins with Unfortunately, not all applications support socks settings ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] [tor-talk] Please review Tails stream isolation plans
On 9/3/12, adrelanos adrela...@riseup.net wrote: Nick Mathewson: Failing that, torsocks is indeed a way pretty good option. I don't think so. It's only a hack. Doesn't work on Windows. APT doesn't work on Windows either. Robert Ransom ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
