- Jun 01, 2014
-
-
Damian Johnson authored
-
Damian Johnson authored
Just checked and we don't need the package_dir entry to include our settings.cfg.
-
Damian Johnson authored
Adjusting the install path to the one actually picked by default.
-
Damian Johnson authored
Minor change to our description. TorCtl has been deprecated long enough that there's probably little point in mentioning it.
-
Damian Johnson authored
At a high level stem parses descriptors by doing the following... 1. Users call stem.descriptor.parse_file(). 2. The parse_file() function uses the @type annotation to guess the descriptor type. 3. It delegates to the parse_file() function of the relevant descriptor class. Every descriptor class has its own parse_file() function. Karsten is starting to serve descriptor files which are multiple descriptors concatenated together. Stem actually already pretty much handles this since I designed our parsers to read Tor's cached descriptors (which are concatenated descriptors as well). The only gotcha is that @type annotations technically aren't valid descriptor content so at step #3 the descriptor classes balk saying so. Working around this by simply skipping @type annotations at the beginning of files.
-
Damian Johnson authored
Short FAQ entry dicussing how to handle metric's new *.tar.xz archives... https://lists.torproject.org/pipermail/tor-dev/2014-May/006884.html
-
- May 31, 2014
-
-
Damian Johnson authored
A while back Karsten tried to hand a tarfile to our parse_file() method and had confusing results... https://trac.torproject.org/projects/tor/ticket/10977 Expanding our parse_file() function so it'll happily handle tarfiles and tar paths. Note that the DescriptorReader, which already had tar support, is keeping its own separate implementation. This is because using the parse_file()'s tar support has a couple drawbacks... 1. The reader then couldn't stop in the middle of handling tarballs. 2. If a tarball contains both descriptor and non-descriptor content then the DescriptorReader can handle that. parse_file(), however, raises an exception.
-
Damian Johnson authored
We were missing a handful of versionadded tags for things being added in 1.2.0.
-
Damian Johnson authored
We use tor's stdout and stderr to determine two things... * at what stage it has bootstrapped to * errors if tor fails to start After startup, however, we stop listing to stdout which can cause Tor to lock up if it's registering a lot of NOTICE level messages... https://trac.torproject.org/projects/tor/ticket/9862 Tested by the following script. Before this fix tor hung after ~3 seconds. With it things happily chug along... import time import stem.process from stem.control import EventType, Controller tor_process = stem.process.launch_tor_with_config( config = { 'ControlPort': '9051', 'Log': 'DEBUG stdout', }, take_ownership = True, ) with Controller.from_port() as controller: controller.authenticate() def heartbeat(event): print "%s - %s / %s" % (time.time(), event.read, event.written) controller.add_event_listener(heartbeat, EventType.BW) print "Press any key to quit..." raw_input()
-
Damian Johnson authored
On reflection both are very well written and tested. I've found these useful in my projects and there's little reason so keep 'em to ourselves so sharing the wealth.
-
- May 29, 2014
-
-
Damian Johnson authored
Citing a ticket where a user indicated that _set_argv() caused issues for them. The user disappeared so not positive if it's really an issue (nor a fix if so).
-
Damian Johnson authored
Whenever launch_tor() finishes, either with success or failure we want to do two things: * stop our alarm if we were running with a timeout * clean up our temporary torrc if we made a blank one We did this in an ad-hoc fashion, but it better belongs in a finally block.
-
- May 28, 2014
-
-
Damian Johnson authored
Adding a Controller method for tor's DROPGUARDS function... https://trac.torproject.org/projects/tor/ticket/10032 https://gitweb.torproject.org/torspec.git/commitdiff/7c6c7fc
-
Damian Johnson authored
For a while now our Fedora page has been getting an error response... https://github.com/fedora-infra/fedora-packages/issues/76 Juan suggested using this link instead until it gets sorted out.
-
- May 27, 2014
-
-
Damian Johnson authored
-
- May 26, 2014
-
-
Damian Johnson authored
Revising our test for /info to account for the recent changes.
-
- May 25, 2014
-
-
Damian Johnson authored
Greatly enriching our /info output to include all relay information the user is likely to find helpful. This revises the summary a bit, but more importantly now includes the relay's hostname and all descriptor content (server, extrainfo, microdescriptor, and router status entry). Fetching both the hostname and descriptor content involves active lookups, but while this was a no-go for arm it's perfectly fine for an interactive interpreter like this.
-
Damian Johnson authored
For a long while we've had an issue where readline history would break with long inputs. For instance, entering... >>> the quick brown fox jumped over the very nice fence and ran around in pretty fields ... then pressing 'up' to autocomplete history then 'down' to go back to an empty prompt would leave a fragment of this mingled with the prompt. This turned out to be an issue with how readline calculates column width. Readline included the formatting sequences when determining our prompts width, which can be corrected by wrapping all encodings with RL_PROMPT_START_IGNORE and RL_PROMPT_END_IGNORE sequences... https://stackoverflow.com/questions/9468435/look-how-to-fix-column-calculation-in-python-readline-if-use-color-prompt Many thanks to Yawning for pointing this out!
-
Damian Johnson authored
Changing 'events' from being a variable to a function. Presently this provides a single optional argument to filter the event types it returns (a very, very common thing to want). This also makes it easier for us to expand in the future as more use cases crop up.
-
- May 24, 2014
-
-
Damian Johnson authored
Patch from Yawning that corrects two things... * Doesn't hardcode tor-prompt to install to /usr/bin so the user can customize it. * Installs the prompt's settings.cfg (without which it won't run).
-
Damian Johnson authored
Adding a tutorial for our new interpreter, giving an overview of both how to run it and what it can do. Think this might be my favorite tutorial yet...
-
Damian Johnson authored
Adding a command to clear the backlog of events we've received.
-
- May 23, 2014
-
-
Damian Johnson authored
Huh. Not sure why my spell checker thought 'interpretor' was ok. Thanks to Yawning for pointing this out.
-
Damian Johnson authored
Renaming our prompt to be less generic so we can add it to bin on installation. I'm not in love with this name, but at least it's pretty self-explanatory.
-
- May 12, 2014
-
-
Damian Johnson authored
I was using our Controller's high level methods (get_info(), get_conf(), add_event_listeners()) for a couple reasons. First they provide caching and second because they yeild more succinct output. But on refection those are both terrible reasons. Caching is worthless with such a low call volume, and it's actually *better* if we print raw Tor responses. This is supposed to provide raw controller accesss, right? :) If users want the behavior of the high level methods then they can now call those easy enough.
-
- May 11, 2014
-
-
Damian Johnson authored
Not everyone will probably want highly colorized output so providing an option to disable it. I dislike this approach of using a global in the stem.util.term module. I'm explicitely not vending this to others since I'm sure there's a more graceful way of toggling this.
-
Damian Johnson authored
Colorizing our prompt's initial output, with bolding to better emphasize the examples.
-
Damian Johnson authored
Our prompt provided two modes: a python prompt or raw controller prompt. But why not combine the two? We now provide a python interpretor (like IDLE), but with the following... * A connection to Tor is available via our 'controller' variable. * Events we've received via SETEVENTS is available via our 'events' variable. * Controller commands we recognized are passed directly to Tor (like our prior prompt). * Python support can be toggled via '/python'. If it's disabled this is effectively our prior prompt. * Starting tor without prompting if it isn't running. Tor only takes a fraction of a second to bootstrap to a state we can use, so asking the user is more of a hassle than help.
-
Damian Johnson authored
PEP8 doesn't have any advice on when to opt for one quote type or the other, so I'm settling on the following: Single quotes unless it's either block quotes (""") or has single quotes in the content ("he said 'hello'").
-
Damian Johnson authored
Just a few minor tweaks. Dropping the examples from the end since we have better example usage earlier now.
-
Damian Johnson authored
Our new prompt does everything the old one does and much more. Dropping the old prompt command.
-
Damian Johnson authored
If tor isn't running then offering to start an instance for our prompt to connect to. This only lasts for the duration of the interpretor session.
-
- May 10, 2014
-
-
Damian Johnson authored
Support for providing the user with a python interpretor when they include the '--python' argument. This is what our old 'prompt' command once provided, and is handy when you'd like to get a quick and easy Controller to interact with.
-
- May 07, 2014
-
-
Damian Johnson authored
Not something our callers will care about (the parameter's just present for collision prevention), so just adding for completeness.
-
- May 06, 2014
-
-
Damian Johnson authored
GSoC by wfn that used stem's DescriptorReader for backfilling descriptors into its DB.
-
Damian Johnson authored
New reasson for the enumeration... https://gitweb.torproject.org/torspec.git/commitdiff/358e8ac97811ff2ad6de34f84fb59a92612b4a08
-
Damian Johnson authored
Noting the recent interpretor and site changes.
-
Damian Johnson authored
Oops, last minute change added a newline to the end of non-interpretor commands. Forgot to update the unit tests to account for this.
-
Damian Johnson authored
Arm's 1.4.5 release included an interpretor panel that allowed raw control port access with usability improvements like... * tab completion * history by pressing up/down * terminal coloring to improve readability * irc-style functions such as '/help' and '/info' This was pretty slick but rarely used, and is being removed from the next arm release. The trouble isn't with the feature, but rather the audience. Raw control port access is useful to learn about tor's controller interface and debug during development. This didn't match arm's audience, who are primarily relay operators and power users. However, it's *perfect* for Stem! This is a rewritten version of arm's interpretor... https://gitweb.torproject.org/arm.git/blob/e249dc8f5c4c282326324161cf8421f947cf660e:/src/util/torInterpretor.py Functionally this is the same as arm's, but is much more modular and better tested. Pending improvements I plan include... * tutorial to introduce new stem users to the prompt * option to get a python prompt (similar to our old 'prompt' command)
-
Damian Johnson authored
-