Install Tor relay on CentOS 7

This is a quick guide to running up a Tor relay on a CentOS 7 server. Firewall config has been omitted, check out these links if you need help with the OS firewall config.
How to setup a firewall using firewalld on CentOS 7
How to migrate from firewalld to iptables on CentOS 7

It’s worth noting that you can score a Tor t-shirt if you run an exit node or relay that satisfies a set criteria:
Tor T-Shirt for contributing!

“Operate a fast Tor relay that’s been running for the past two months: you are eligible if you allow exits to port 80 and you average 250 KBytes/s traffic, or if you’re not an exit but you average 500 KBytes/s traffic.”

Let’s get started.

Create the .repo file below.

vim /etc/yum.repos.d/torproject.repo

[tor]
name=Tor repo
enabled=1
baseurl=https://deb.torproject.org/torproject.org/rpm/el/7/$basearch/
gpgcheck=1
gpgkey=https://deb.torproject.org/torproject.org/rpm/RPM-GPG-KEY-torproject.org.asc

[tor-source]
name=Tor source repo
enabled=1
autorefresh=0
baseurl=https://deb.torproject.org/torproject.org/rpm/el/7/SRPMS
gpgcheck=1
gpgkey=https://deb.torproject.org/torproject.org/rpm/RPM-GPG-KEY-torproject.org.asc

Install Tor through yum.


yum -y install tor


Edit the config file for Tor.


vim /etc/tor/torrc

SOCKSPort 0
Log notice file /var/log/tor/notices.log
RunAsDaemon 1
DataDirectory /var/lib/tor
#Listen port
ORPort 443
#IP Address or DNS name of your relay.
Address cheddar.cheese.sexy
#The name of your relay.
Nickname chsxy
#If you're worried about spam then you really don't want to format the email address like I have here.
ContactInfo oh boy suddenly all this spam is going to - [email protected]
DirPort 9058
# no exits allowed.
ExitPolicy reject *:*

Verify the config to make sure there are no issues.

tor -f /etc/tor/torrc --verify-config

Run Tor.

/etc/init.d/tor start
Starting tor...done.
/etc/init.d/tor status
tor (pid 3666) running

Check the log file to make sure everything is running smoothly.

tail -f /var/log/tor/notices.log

Aug 28 04:19:43.000 [notice] I learned some more directory information, but not enough to build a circuit: We need more descriptors: we have 5382/6917, and can only build 50% of likely paths. (We have 77% of guards bw, 79% of midpoint bw, and 81% of exit bw = 50% of path bw.)
Aug 28 04:19:43.000 [notice] Bootstrapped 80%: Connecting to the Tor network
Aug 28 04:19:44.000 [notice] Bootstrapped 85%: Finishing handshake with first hop
Aug 28 04:19:44.000 [notice] Bootstrapped 90%: Establishing a Tor circuit
Aug 28 04:19:45.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Aug 28 04:19:45.000 [notice] Bootstrapped 100%: Done
Aug 28 04:19:45.000 [notice] Now checking whether ORPort 163.172.170.23:443 and DirPort 163.172.170.23:9058 are reachable... (this may take up to 20 minutes -- look for log messages indicating success)
Aug 28 04:19:45.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Aug 28 04:19:45.000 [notice] Self-testing indicates your DirPort is reachable from the outside. Excellent.
Aug 28 04:19:46.000 [notice] Performing bandwidth self-test...done.

After a couple of hours you should be able to see your relay on one of the various index sites!

Here’s mine.

This particular relay is hosted over at Scaleway.

Running fsck via Leaseweb FreeBSD Rescue 2.1 on UFS partitions

I’ve been running a FreeBSD 10 based dedicated server with Leaseweb NL for a little over a year now. This morning I noticed the server was down.

Unfortunately Leaseweb don’t seem to provide any KVM style access, or in any case I don’t have that functionality with this server from them. I rebooted the server via the Leaseweb panel, without any success. My suspicion was that the filesystem might be dirty, and FreeBSD was stuck on a screen waiting for fsck to be launched.

Using Leaseweb’s panel I booted into their “FreeBSD Rescue 2.1”. I tried to run fsck across my partitions, however I would constantly get the error:
fsck: Could not determine filesystem type

For this particular server I am still using UFS rather than ZFS. It turns out you have to define the type in the fsck command.

In the end I did the following:
ls /dev/ad* #to list out all partitions
fsck -y -t ufs /dev/ad3s1 #ran this same command across every partition

It was the /usr partition that was marked as “dirty”. After running the above fsck command across it, I rebooted the server and everything came back as normal.

Lossless video capture without needing fast and huge storage – x264vfw

To get the best quality out of your video captures, it’s best to capture losslessly and encode the content post-capture rather than trying to do it in real-time via software encoding or using hardware encoders. Unfortunately normal raw lossless capturing requires very fast storage and a pretty hefty amount of disk space. SSD drives can cope, but depending on the length of your captures you may well need over 2TB of space, which is currently quite expensive in SSD form. An alternative is to use RAID0 arrays or similar. If your storage cannot keep up with the required write speeds you will end up with dropped frames.

x264vfw
amarectv & x264vfw

A great solution is using the x264vfw codec in lossless mode. You will still have large file sizes (expect past 1GB or more for every minute), however the sizes are much smaller than normal raw lossless capture. This also means the write speeds required for capturing without losing any frames are lower. The highest I’ve seen x264vfw jump in lossless mode is ~60MB/s when a ton of action is going on, otherwise in my captures I’ve seen speeds generally hang around 20MB/s. A standard HDD can cope with this without issue, just make sure the drive isn’t being used by anything else.

For more info on x264vfw, other lossless codecs, and capturing in general – Check out “TheThrillness Blog”.

 

Fixing “Can’t connect to Group Policy Client service” on Windows 10

This is the method I’ve used to fix the “Can’t connect to Group Policy Client service” error on Windows 10. Symptoms – Log into Windows, no desktop icons, start bar not really working, and a little lock icon in the taskbar with that error message. A system restore will probably fix this problem, however it wasn’t an option for me as I’ve disabled the system restore feature.

In the start bar type cmd so that you see the command prompt shortcut.

Right click it and run as Administrator.

Type netsh and press enter.

Type winsock reset and press enter.

Reboot the PC.

This might not work on your first try, so try it twice just to be sure.

You should now be back at a working desktop after logging in.
Go to Start > Settings > System > Power and sleep > Additional power settings

Click on choose what the power buttons do over on the left.

Scroll down to shutdown settings.

Uncheck turn on fast startup
(If this is greyed out, up the top you need to first click “change settings that are currently unavailable”)

Save the changes.

TPG FTTN NBN Speeds

Roughly three months have passed since connecting to NBN FTTN via TPG. I’m on the “up to” 100/40mbit plan. At a guess I’m ~500meters from the node. At this point I haven’t had any issues with the horrible speeds/congestion that some users report. FTTN sucks compared to FTTH for a ton of reasons that I won’t go into. The bottom line so far is that I’m more or less able to saturate the speed that I’m syncing up at regardless of peak/offpeak.

Modem Stats (TPG supplied Huawei HG-658)
Line standard VDSL2
Channel type Interleaved
Downstream line rate (kbit/s) 62945
Upstream line rate (kbit/s) 29311
Downstream SNR (dB) 6.7
Upstream SNR (dB) 6.5
Downstream line attenuation (dB) 15
Upstream line attenuation (dB) 5.1
Downstream output power (dBmV) 14.3
Upstream output power (dBmV) 8.4

Speedtest.net

Speedtest.net result - Unusually high latency from the server on this result.
Speedtest.net result – Unusually high latency from the server on this result. I’ve seen much better results matching right to the sync speed.

Speedtest.net – (Updated 08/09/2016)

Ahhh that's more like it!
Ahhh that’s more like it!

LFTP segmented download from NL based server

6.63MB/s
6.63MB/s

Segmented SFTP downloading using LFTP

If you’ve every tried saturating a fast connection using FTP/SFTP you may have run into problems where you can only achieve limited download speeds using a single thread. Segmented downloading can often be a solution. Bare in mind that segmented FTP/SFTP will open many sessions to the server you are connecting to. Depending on the situation this might not be ideal, however if you’re sure you have sufficient resources to do it (without pissing anyone off if the server is in shared environment), then it can work very well. For example – From my home connection I can usually only pull ~800KB/s on a single thread SFTP download from a dedicated server based in the Netherlands. Using segmented downloading I can easily max out my connection (~7MB/s). I’ve found that other software such as Bitkinex and CuteFTP on Windows are not able to match the speeds I get when using lftp.

You’ll need to install lftp – I run it on my Raspberry Pi.
sudo apt-get install lftp

Login to your server using lftp
lftp sftp://[email protected]

Change into the directory with files you want to download
cd /hdd01/downloads

Start a segmented download

A pget command using segmentation is used for single files.
pget -n 15 somefile.iso #where 15 is the number of segments

A mirror command using segmentation is for downloading whole directories.
mirror --use-pget-n=15 SomeDirectory #where 15 is the number of segments

You’ll need to experiment with the amount of segments – It’s best to use as few as you can, while still getting as much speed as you need. I tend to use 8 – 15 at absolute maximum.

lftp has queue support which can also be pretty useful. Essentially you can queue up a bunch of different transfers and pull up the status later on. You simply need to add queue to the start of your command. To check the queue you can use jobs -v