In stem.process.launch_tor_with_config
How can we specify the circuit to be used by Tor?
In the config dict for launch_tor_with_config(), you can specify which entry and exit nodes to use/exclude, as well as excluding specific relays from being used in circuits (assuming StrictNodes == 1). But there is no way to define specific circuits to use from within the config there.
You can use the extend_circuit() function from the stem.Controller library to create circuits with a specified path, listing the relay fingerprints you want the circuit to use.
To define your own circuits and ensure that Tor doesn't automatically replace them:
(1) In the config that you use to launch_tor_with_config(), set NewCircuitPeriod and MaxCircuitDirtiness to very high values, so that circuits are not automatically destroyed. The default is that they are marked dirty and not used for new connections 600 seconds (10 mins) after their first use. This means that your custom circuits will likely be automatically replaced after 10 mins, unless you tell Tor not to. The maximum value for MaxCircuitDirtiness is 30 days. The config option MaxCircuitDirtiness is specified in seconds, so this would be 60⋅60⋅24⋅30 = 2592000 seconds. If your application needed to run continuously for longer than 30 days, you would have to manually destroy/create new circuits every month or so ...
(2) Create the desired circuits with extend_circuit(). As described in the documentation, you basically just provide a list of relay fingerprints to define the path you want for the circuit. For example:
controller.extend_circuit('0', ['718BCEA286B531757ACAFF93AE04910EA73DE617',
'30BAB8EE7606CBD12F3CC269AE976E0153E7A58D',
'2765D8A8C4BBA3F89585A9FFE0E8575615880BEB'])
... the first argument '0' tells it to create a new circuit using the path specified in the list.
(3) close all other circuits that were created by default with Stem.controller.close_circuit()
If you do the above, the only circuits that should exist are the ones with the paths you created, and they would not be marked dirty and get replaced for 30 days.
Related
When doing scanning with passive RFID tags, you can set the SESSION to '2' in order for the tag state of 'B' to persist for "an indefinite amount of time" even when it is not being energized by the scanner, according to the standards. Your tag will then not be visible to the scanner until this indefinite amount of time expires.
My question is, does anyone have any idea what the maximum amount of time is for RFID tags? I'm sure it's different for different tag manufacturers , etc. However, are we talking seconds, minutes, hours, or even days? I don't want to keep seeing the same tags over and over again while doing a scan in the storeroom, but at the same time, I don't want the tag to be hidden if they need to be scanned again at a later time.
The answer is: it depends. Please note that the standard says 'indefinite when powered'. When powered, it is really indefinite. When not powered, the standard defines it is longer than 5 seconds. For most modern tags, it is typically less than 30s, of course depending on environment conditions.
About the definition of 'powered': please note that this power can originate from any RFID reader, not only the one you are using to interrogate the tags with. Or any other radio device that transmits at the same frequency.
To circumvent this, you can use a SELECT statement to revert the session flag back from B to A.
I am currently tracing cannot fork() errors on my Ubuntu Server and I was able to pinpoint it to the pid.max value of 700 under /sys/fs/cgroup/pids/.
However, I can only able to set the values /system.slice/pids.max and /user.slice/pids.max - not pids.max. Plus, these reset after reboot to the value max which again enforces the global pids.max value.
Is it possible to simply change the it from 700 to something higher? root + sudo were of no help.
Is there another way to override this value?
After a long back and forth with my server hoster, they finally spilled the beans.
I was renting a V-Server with very beefy hardware for very little money. The catch? You can only run 700 concurrent tasks. That's where the pids.max value came from and overruled the TasksMax and numprocs values.
I think you're looking for DefaultTasksMax= directive from /etc/systemd/system.conf.
You can check the runtime value by issuing systemctl show -p DefaultTasksMax:
$ systemctl show -p DefaultTasksMax
DefaultTasksMax=19096
If you wish to change it, simply edit the respective directive line in /etc/systemd/system.conf. Similar directive (TasksMax=) exists to tweak this setting on per-unit basis.
Relevant documentation[0][1] snippets:
TasksMax=N
Specify the maximum number of tasks that may be created in the unit. This ensures that the number of tasks accounted for the unit (see above) stays below a specific limit. This either takes an absolute number of tasks or a percentage value that is taken relative to the configured maximum number of tasks on the system. If assigned the special value "infinity", no tasks limit is applied. This controls the "pids.max" control group attribute. For details about this control group attribute, see Process Number Controller.
The system default for this setting may be controlled with DefaultTasksMax= in systemd-system.conf(5).
DefaultTasksMax=
Configure the default value for the per-unit TasksMax= setting. See systemd.resource-control(5) for details. This setting applies to all unit types that support resource control settings, with the exception of slice units. Defaults to 15%, which equals 4915 with the kernel's defaults on the host, but might be smaller in OS containers.
I am trying to edit my torrc and make all of the nodes funnel through one country.
So far I am able to force the entry and exit nodes but don't know how to change the middle node... any ideas?
I have already tried "MiddleNodes" and "RelayNodes"
EntryNodes {us},{ca}
ExitNodes {us},{ca}
StrictNodes 1
It's possible to restrict to MiddleNodes per Tor docs: https://2019.www.torproject.org/docs/tor-manual.html.en
MiddleNodes node,node,…
A list of identity fingerprints and country
codes of nodes to use for "middle" hops in your normal circuits.
Normal circuits include all circuits except for direct connections to
directory servers. Middle hops are all hops other than exit and entry.
This is an experimental feature that is meant to be used by
researchers and developers to test new features in the Tor network
safely. Using it without care will strongly influence your anonymity.
This feature might get removed in the future. The HSLayer2Node and
HSLayer3Node options override this option for onion service circuits,
if they are set. The vanguards addon will read this option, and if
set, it will set HSLayer2Nodes and HSLayer3Nodes to nodes from this
set. The ExcludeNodes option overrides this option: any node listed in
both MiddleNodes and ExcludeNodes is treated as excluded. See the
ExcludeNodes option for more information on how to specify nodes.
Edit: See new answer by #user1652110 describing MiddleNodes option which was added in January 2019.
There is no option to do so. The closest option you can try is ExcludeNodes by using as large a list of country codes as you can come up with that doesn't include the countries you do want to use.
Also note, at the time of writing, limiting your circuits' entry and exit points to relays in the US and Canada might severely limit your performance, anonymity, and reliability since there just aren't that many high-bandwidth exits and guards in these two countries.
I have the following problem:
I want to do the statistics of data that need to be constantly increasing. For example, the number of visits to the link. After some time be restarted these visit and start again from the beginning. To have a continuous increase, want to do the statistics somewhere. For this purpose, use a site that does this. In his condition can be used to COUNTER, GAUGE, AVERAGE, ... a.. I want to use the COUNTER. The system is built on Nagios.
My question is how to use this COUNTER. I guess it is the same as that of the RRD. But I met some strange things in the creation of such a COUNTER.
I submit the values ' 1 ' then ' 2 ' and the chart to come up 3. When I do it doesn't work. After the restart, for example, and submit again 1 to become 4
Anyone dealt with these things tell me briefly how it works with this COUNTER.
I saw that the COUNTER is used for traffic on routers, etc, but I want to apply for a regular graph, which just increases.
The RRD data type COUNTER will convert the input data into a rate, by taking the difference between this sample and the last sample, and dividing by the time interval (note that data normalisation also takes place and this is dependent on the Interval setting of the RRD)
Thus, updating with a constantly increasing count will result in a rate-of-change value to be graphed.
If you want to see your graph actually constantly increasing, IE showing the actual count of packets transferred (for example) rather than the rate of transfer, you would need to use type GAUGE which assumes any rate conversion has already been done.
If you want to submit the rate values (EG, 2 in the last minute), but display the overall constantly increasing total (in other words, the inverse of how the COUNTER data type works), then you would need to store the values as GAUGE, and use a CDEF in your RRDgraph command of the form CDEF:x=y,PREV,+ to obtain the ongoing total. Of course you would only have this relative to the start of the graph time window; maybe a separate call would let you determine what base value to use.
As you use Nagios, you may like to investigate Nagios add-ons such as pnp4nagios which will handle much of the graphing for you.
Everyone knows that MRTG needs at least one value to be passed on it's input.
In per-target options MRTG has 'gauge', 'absolute' and default (with no options) behavior of 'what to do with incoming data'. Or, how to count it.
Lets look at the elementary, yet popular example :
We pass cumulative data from network interface statistics of 'how much packets were recieved by the interface'.
We take it from '/proc/net/dev' or look at 'ifconfig' output for certain network interface. The number of recieved bytes is increasing every time. Its cumulative.
So as i can imagine there could be two types of possible statistics:
1. How fast this value changes upon the time interval. In oher words - activity.
2. Simple, as-is growing graphic that just draw every new value per every minute (or any other time interwal)
First graphic will be saltatory (activity). Second will just grow up every time.
I read twice rrdtool's and MRTG's docs and can't understand which option mentioned above counts what.
I suppose (i am not sure) that 'gauge' draw values as is, without any differentiation calculations (good for measuring how much memory or cpu is used every 5 minutes). And default or 'absolute' behavior tryes to calculate the speed between nearby measures, but what's the differencr between last two?
Can you, guys, explain in a simple manner which behavior stands after which option of three options possible?
Thanks in advance.
MRTG assumes that everything is being measured as a rate (even if it isnt a rate)
Type 'gauge' assumes that you have already calculated the rate; thus, the provided value is stored as-is (after Data Normalisation). This is appropriate for things like CPU usage.
Type 'absolute' assumes the value passed is the count since the last update. Thus, the value is divided by the number of seconds since the last update to get a rate in thingies per second. This is rarely used, and only for certain unusual data sources that reset their value on being read - eg, a script that counts the number of lines in a log file, then truncates the log file.
Type 'counter' (the default) assumes the value passed is a constantly growing count, possibly that wraps around at 16 or 64 bits. The difference between the value and its previous value is divided by the number of seconds since the last update to get a rate in thingies per second. If it sees the value decrease, it will assume a counter wraparound at 16 or 64 bit. This is appropriate for something like network traffic counters, which is why it is the default behaviour (MRTG was originally written for network traffic graphs)
Type 'derive' is like 'counter', but will allow the counter to decrease (resulting in a negative rate). This is not possible directly in MRTG but you can manually create the necessary RRD if you want.
All types subsequently perform Data Normalisation to adjust the timestamp to a multiple of the Interval. This will be more noticeable for Gauge types where the value is small than for counter types where the value is large.
For information on this, see Alex van der Bogaerdt's excellent tutorial