'aptitude update' - fails (most of the time?) [on whonix-gateway only, it turns out]

Support
1

[New to whonix, just sinking into the beasties …]

Why does aptitude update fail (almost?) all the time? e.g.

Err http://ftp.us.debian.org jessie InRelease
…
Temporary failure resolving ‘ftp.us.debian.org’
…
W: Failed to fetch http://security.debian.org/dists/jessie/updates/InRelease:
…
W: Some index files failed to download. They have been ignored, or old ones used instead.

Seems to me I have seen it work - perhaps only shortly after boot time / while Tor is establishing itself?

  • is there a link that explains what’s going on / why it sometimes works but mostly doesn’t / how to work with it?

Now, to be fair … I only just noticed that apt-get update seems to work just fine - but I have always used / am used to ‘aptitude’. (Let alone aptitude upgrade not apt-get dist-upgrade. Never mind safe-upgrade.) Each to his own, it just took me a long time to figure this out. (That’s not a complaint.)

Similarly, I only just noticed that it is fine on whonix-workstation, it’s only on whonix-gateway where I see this.

So, I guess my real question is … is there a link towards descriptions of why this is working the way it is on whonix-gateway, advice (against, no doubt) installing software on whonix-gateway, and issues surrounding such?

e.g. seems to me that nslookup and ping fail too. traceroute even. However, nslookup now appears to be working, ping not working makes sense, and nslookup -4T effects the same connectivity sanity check. (But shows no path steps - no doubt intentional / a good thing.)

  • which is all to say, I guess in my reading through the wiki I missed any ‘nature of the whonix-gateway environment’ section. Any links?

[I get the standard disclaimer, any changes potentially increases your exposure or potential for anonymizing failure, etc.]

  • and, in writing this, I notice that cut and paste (the clipboard) between host and whonix-workstation works fine, but not whonix-gateway. Pointers to links explaining that would also be welcome.

Kubuntu LTS w/ virtualbox

2

https://www.whonix.org/wiki/VirtualBox_Guest_Additions#Clipboard_Sharing

3

D’OH! Did read that too … thanks. Guess I lost sight of it.[quote]Security Guide - Whonix did read that, but that doesn’t seem to answer the question of why aptitude fails.

What have I missed / overlooked?

4

But apt-get does work?

5

You already said above it does… So… Another answer soon.

6

Possible. Run whonixcheck to see if it’s fully able to establish outgoing connections.[quote=“rAntOCauDgb, post:1, topic:1724”]
is there a link that explains what’s going on / why it sometimes works but mostly doesn’t / how to work with it?
[/quote]
I don’t think so because nothing Whonix does discriminates apt-get vs aptitude.[quote=“rAntOCauDgb, post:1, topic:1724”]
e.g. seems to me that nslookup and ping fail too. traceroute even. However, nslookup now appears to be working, ping not working makes sense, and nslookup -4T effects the same connectivity sanity check. (But shows no path steps - no doubt intentional / a good thing.)
[/quote]
Note, Whonix-Gateway has transparent proxying disabled by default which can be optionally enabled. ( Whonix-Gateway Traffic: Transparent Proxying )
So any extra applications not configured explicitly to use a Tor SocksPort on the gateway will fail unless you enable transparent proxying for the gateway’s own traffic. (I haven’t heard a use case yet where this would make sense.)

https://www.whonix.org/wiki/VirtualBox_Guest_Additions#Shared_Folder

From a users perspective, everything you need to know can be find in the documentation. From a developers perspective, I was wondering for a long time already if any kind of design documentation makes sense anyhow. It only increases the total amount of stuff to read to fully know what Whonix does and what not. This higher total amount results, as I suspect, to fewer people going to even start reading. Best to have the rationale, the design, the explanations why X and Y is done in Z way and not otherwise directly in the source code as comments. Otherwise design documentation gets to look more complicated, outdated as things develop, confusing, etc.

7

Fair and good points. (Add more than oneself to have to commonly understand something and it seems that the energy that has to be expended rises exponentially. And is why projects eagerly greet non-coders willing to document, moderate, etc.)

wiki kudos though - the conscious use of expand has been VERY helpful and appreciated. Skip some, open some, come back later others. Sinking into this has been overwhelming - so many disparately moving pieces and interactions to keep track of. And I think of myself as a net/security computer guy with no little expertise, even. What has become clear, though, is I’m not nearly paranoid enough (and have no real reason to be). And I’m also convinced that even the most paranoid aren’t nearly paranoid enough. [So, one has to become as paranoid as they are able / can tolerate to be, evolving every day - but it will never be paranoid enough, and one just has to live with that.]

As for documentation, as you note / hint … making it much like code is helpful. i.e. Principle and design/approach documents cross-linking with technical discussions / links, leading to code, etc. Much like rationalizing a database, or breaking up a bit of code into sub-functions. Agreed - non-trivial amount of work, vs just blasting in a few pages of code comments.

Thanks for the reminder … I had quite forgotten about comments in code (one doesn’t really even have to be able to read code - comments are, well, prose). And is, after all, the availability of which is a base tenet inherent to FOSS. D’OH!

8

OK, I think I see what’s going on / what’s happened.

[Having now come / bumbled across things like anondist and uwt.]

Using apt-get as the template …

IIRC, aptitude doesn’t come installed with whonix / base Debian.

Installing it causes /usr/bin/aptitude to be linked to /etc/alternatives/aptitude

The following seems to let aptitude do the expected:

root@host:/usr/bin# mv aptitude aptitude.anondist-orig
root@host:/usr/bin# ln -s /usr/bin/aptitude.anondist /usr/bin/aptitude

i.e. the ‘mv aptitude’, aptitude currently being a link to /etc/alternatives/aptitude, the link goes along for the ride.

Don’t know whether I botched something during initial install / exploration or not. i.e. Whether there is something to fix here within the vm source.

Presumably the vm source can’t establish /usr/bin/aptitude (-> aptitude.anondist) as aptitude’s not yet installed. apt-get aptitude is going to schmuck any such anyways.(aptitude.anondist is there, which is fine and wonderful.)

If this is indeed an issue present at install time, seems like either the vm should come with aptitude installed, or the whole /etc/alternatives beastie be grokked and fingers poked in the right places.

The description above duplicates what I see on whonix-workstation. Presumably, by design, aptitude works fine there, as expected.

9

Confirmed.

Developments notes:

  • uwt ( GitHub - Whonix/uwt ) has no issue with applications that are installed after uwt. (Can be tested using a rather uncommon application rawdog.)

  • Seems like a newer version of aptitude, that is now using Debian ‘alternatives’ mechanism is now incompatible with uwt by default.

  • /etc/alternatives/aptitude is a symlink to /usr/bin/aptitude-curses. To easy, but maybe not so clean fix would be to apply uwt to /usr/bin/aptitude-curses rather than /usr/bin/aptitude.

  • A better fix migth be to apply uwt to /etc/alternatives/aptitude rather than /usr/bin/aptitude, but this may not work. Debian ‘alternatives’ mechanism may not honor dpkg diversions.

  • More generally speaking, it seems like uwt has a bug “incompatible with Debian ‘alternatives’ mechanism”.

10

[quote=“Patrick, post:9, topic:1724”]
… /etc/alternatives/aptitude is a symlink to /usr/bin/aptitude-curses. To easy, but maybe not so clean fix would be to apply uwt to /usr/bin/aptitude-curses rather than /usr/bin/aptitude.[/quote]

I would not suggest that. The common always working point of entry will be (/usr/bin/)aptitude. Where it points to, presumably links within /etc/alternatives to elsewhere, may change at any time underneath you.

I can’t speak to that, but I can say … it would be useful if /usr/lib/uwtwrapper --help returned the expected.

11

Implemented:

12

It’s not yet tested.

13

Doesn’t work. Working on it.

14

This should work. Tested.

15

Implemented:[quote]GitHub - Whonix/uwt

  • implemented uwtwrapper --help
    by adrelanos on 03:59PM - 10 Dec 15[/quote][/quote]

[Apologies for the interface munging adrelanos’ quoting.]

Reading the git reference - implemented uwtwrapper --help · Whonix/uwt@9a3c180 · GitHub - not what I was looking for in requesting --help.

No offence, but the listed change, instead of being a typical --help list of parameters seems more suited for a ‘uwtwrapper --about’ type of thing. Or a man page.

I did, however, get from that commit link to do ‘man uwt’. (Which wasn’t intuitive to do, at the time.)

So … perhaps useful to explain how I got here / to make the request.

Being new to whonix, and stumbling across ssh.anondist, and seeing the “/usr/lib/uwtwrapper ${1+”$@“}” within it, I naturally went /usr/lib/uwtwrapper --help, then man uwtwrapper.

Expecting to see something along the lines of ‘uwtwrapper {prog} {ip} {port} {proxy}’ or something - i.e. following the breadcrumbs of this whonix thingy I’m new to.

From what I can see from the commit link, that level of concise --help output is not present.

Was just looking to follow the breadcrumbs at the time.

So a help page of the form:

  • From uwt: /usr/lib/uwtwrapper [-h] [-v] -t server_type -i ip -p port command [options…]
  • expected to be used by developers only.
  • do not use if you do not know what you are doing.
  • see man uwtwrapper, man uwt, and the whonix wiki for more information

Would have done it.

If I understand the commit link, such is still not present.

At the time was trying to understand / follow the flow of what I was in the middle of. Since then, I’ve come across the wiki articles, port list / documentation, seen rinetd.conf, and understand that there are proxies and redirects and other magic going on.

So, when I get back to this point, trying things out manually at the command line before scripting things … I’m going to be looking for that --help concise argument list again.

So, no offence, but if I read the commit link correctly, I see a lot of verbiage I wouldn’t be interested in (find annoying even), (and still no easy / quick parameter list), for where I was at / was looking for at the time of needing to call --help.

16

The user answer currently is:
Forget about uwtwrapper. Use uwt.

The developer answer currently is:
Rewrite/redesign/etc. contributions happily considered. It’s low priority for me, it works good enough, and because I still have hope we one day get torsocks feature ‘choosing ip / port by command line’ . Then uwt and uwtwrapper can be deprecated. And the uwtwrappers can be modified to use torsocks.

17

The simple interface you are requesting doesn’t exist. And it’s not simple to implement. One of the key features is, being able to disable all uwtwrappers globally. To avoid code duplication, uwtwrappers are kept small and all the logic lives inside /usr/lib/uwtwrapper.

It’s historically grown. If I would reimplement/rework it now, I would perhaps set the ports from within the wrappers. Then the ports would perhaps be hardcoded (since in /usr/bin - not preserving modifications on updates). However important that is. [Would still be possible to allow to override them from /etc/uwt.d.) That would make how to create ones own wrapper simpler and more self-explanatory. Setting perhaps the ports by environment variables. By command line parameters is not simple to get right as it can conflict with the command line parameters for the actual application to start. Wasn’t simple to get uwt work flawlessly. Got tricky at nested invocations. (uwtwrapped git starts its own instance of ssh which then also gets uwtwrapped.)

I don’t want to spend too much time on it, since there is a flood of other tasks, and for above reasons.

18

Not sure what you’re responding to, there, but if either --help request, or Quick Whonix Help desktop icon request …

These two elements help the new (admin) user sink into whatever this new beastie is.

Be it to follow what’s going on, or to template uwtwrapper use in an additional fashion to contribute back to the community, first one must grok the current environment. (e.g. --help even visible to see/follow to use uwt instead.)[Only a ‘geek’ is even going to use --help or man in the first place.]

Once the current environment is under one’s belt, one can consider a rewrite / paradigm change, but not until.

In the mean time, doubtless “it works good enough”, but one can’t use it if one can’t follow it to so contribute.

19

The reply was only about uwt. Grasping uwt or a rewrite of it is not be rocket science. ( Frequently Asked Questions - Whonix ™ FAQ ) Just requires knowledge of shell scripting and some Debian packaging. Just look at the package file by file.

Full file list.

./GPLv3
./usr/lib/uwtwrapper
./usr/lib/uwt/uwt.sh
./usr/bin/git.anondist
./usr/bin/time_privacy
./usr/bin/gpg.anondist
./usr/bin/uwt
./usr/bin/mixmaster-update.anondist
./usr/bin/yumdownloader.anondist
./usr/bin/yum.anondist
./usr/bin/rawdog.anondist
./usr/bin/wget.anondist
./usr/bin/aptitude-curses.anondist
./usr/bin/curl.anondist
./usr/bin/apt-get.anondist
./usr/bin/ssh.anondist
./usr/share/lintian/overrides/uwt
./changelog.upstream
./debian/uwt.maintscript
./debian/control
./debian/uwt.undisplace
./debian/uwt.displace-extension
./debian/compat
./debian/source/format
./debian/source/lintian-overrides
./debian/changelog
./debian/gain-root-command
./debian/watch
./debian/copyright
./debian/uwt.displace
./debian/rules
./man/time_privacy.1.ronn
./man/uwt.1.ronn
./etc/X11/Xsession.d/20uwt
./etc/sudoers.d/uwt
./etc/uwt.d/30_timeprivacy_default.conf
./etc/uwt.d/30_uwt_default.conf
./etc/profile.d/20_uwt.sh
./CONTRIBUTING.md
./COPYING
./README.md
./Makefile

The files that matter here.

./usr/lib/uwtwrapper
./usr/lib/uwt/uwt.sh
./usr/bin/time_privacy
./usr/bin/uwt
./usr/share/lintian/overrides/uwt
./debian/uwt.maintscript
./debian/control
./debian/uwt.undisplace
./debian/uwt.displace-extension
./debian/source/lintian-overrides
./debian/uwt.displace
./debian/rules
./etc/uwt.d/30_timeprivacy_default.conf
./etc/uwt.d/30_uwt_default.conf

9 of them are rather small and less in need of change.

And the wrappers. They look a lot, but it’s always the same content and a really small file.

./usr/bin/git.anondist
./usr/bin/gpg.anondist
./usr/bin/mixmaster-update.anondist
./usr/bin/yumdownloader.anondist
./usr/bin/yum.anondist
./usr/bin/rawdog.anondist
./usr/bin/wget.anondist
./usr/bin/aptitude-curses.anondist
./usr/bin/curl.anondist
./usr/bin/apt-get.anondist
./usr/bin/ssh.anondist

Now, when I add more documentation on that, it makes the total amount of stuff to read longer. Therefore creating more confusion than making it simpler.

20

I haven’t asked for a simple interface.

Merely help to follow what’s already there.

e.g. If --help or set -v/-x flushes out what’s within “${1+”$@“}”, when one finds such useful, one can contribute corresponding myfavrouitebinary.anondists’s back.

I grant you, (now) I know to ‘man uwt’, but the initial point was there was no way to discern that up front. (And would have saved the energy we have expended in composing these messages.) Thus the --help request.

As only a ‘geek’ will use --help or man, only a simple --help parameter list will be useful to such.

Similarly, ‘quick whonix help’ desktop icon == whonix, when otherwise not visible / not geek inclined to find - provides a geek sufficient pointer to (work) already (done/contributed) documentation.

I suspect we are commenting on non-correlated aspects here / I am getting confused as to which comments regard which points.