Apr 05

headless crashplan backup target server

Following this I created a headless crashplan instance on my dedicated server. This can then be used by all your computers as a backup target even with the free crashplan tier.

Crashplan needs a java runtime on your machine:
pacman -S java-runtime

Now install crashplan itself:

packer -S crashplan (or use any other AUR-helper)
and start it:
systemctl start crashplan

Once you're done with that, you'll just have to configure the headless server.
Open up ui.properties in the crashplan conf directory (usually /opt/crashplan/conf) and change your servicePort to something like 2323.

Just create a portforward to your host like this:
ssh -L 2323:localhost:4243 root@server

So you can fire up CrashPlanDesktop and do a normal configuration.
Now
On your other computers you can just select your new server as backup destination and you're all set.

If you want crashplan to start up with your machine (should you ever have to reboot it), add it to the system scripts:
systemctl enable crashplan

Share

Apr 24

route ipv6 /64 via openvpn

Although many believe splitting up a /64 net shouldn't be done at all, you sometimes don't have a choice. Say you did get a /64 network from your serverhoster and you want to use it to get native ipv6 to every client in your vpn.

Here you go, for this example we use feed:dead:beef:affe/64 as our basenet :) Every client gets a /80 subnet, feel free to adjust

Server side config:
Just a basic openvpn server config with the three scripts from below linked.
server.conf
port 1195
proto udp
dev tap
ca ca.crt
cert mondialu.crt
key mondialu.key
tls-auth ta.key 0
dh dh2048.pem
server 10.23.1.0 255.255.255.0
script-security 2
up /etc/openvpn/server-up.sh
client-connect /etc/openvpn/client-connect.sh
client-disconnect /etc/openvpn/client-disconnect.sh
ifconfig-pool-persist ipp.txt
keepalive 10 120
comp-lzo
user vpn
group vpn
persist-key
persist-tun
status openvpn-status.log
verb 3

Bring up the routing and neighbor proxy.

server-up.sh
#!/bin/sh
echo 1 > /proc/sys/net/ipv4/ip_forward
echo 1 > /proc/sys/net/ipv6/conf/all/forwarding
echo 1 > /proc/sys/net/ipv6/conf/eth0/proxy_ndp

Add the /80 to the interface and set the appropriate route. Add the new network to the neighbor proxy table.
client-connect.sh
#!/bin/bash
BASERANGE="feed:dead:beef:affe"
V6NET=$(echo ${ifconfig_pool_remote_ip} | awk -F. '{print $NF}')
# config routing for the new network
sudo /sbin/ip -6 addr add ${BASERANGE}:${V6NET}::1/80 dev $dev
sudo /sbin/ip -6 route add ${BASERANGE}:${V6NET}::/80 via ${BASERANGE}:${V6NET}::2 dev ${dev} metric 1
# add neighbor
sudo /sbin/ip -6 neigh add proxy ${BASERANGE}:${V6NET}::2 dev eth0
# log to syslog
echo "${script_type} client_ip:${trusted_ip} common_name:${common_name} local_ip:${ifconfig_local} \
remote_ip:${ifconfig_pool_remote_ip} sit:${SITID} ipv6net:${V6NET}" | /usr/bin/logger -t ovpn

Tear everything down.

client-disconnect.sh
#!/bin/bash
BASERANGE="feed:dead:beef:affe"
V6NET=$(echo ${ifconfig_pool_remote_ip} | awk -F. '{print $NF}')
sudo /sbin/ip -6 addr del ${BASERANGE}:${V6NET}::1/80 dev ${dev}
# log to syslog
echo "${script_type} client_ip:${trusted_ip} common_name:${common_name} local_ip:${ifconfig_local} \
remote_ip:${ifconfig_pool_remote_ip} sit:${SITID} ipv6net:${V6NET} duration:${time_duration} \
received:${bytes_received} sent:${bytes_sent}" | /usr/bin/logger -t ovpn

client config

Typical openvpn client config.

client.conf
dev tap
proto udp
remote your.hostname.de 1195
script-security 2
cert mondialu-maya.crt
key mondialu-maya.key
ca mondialu-ca.crt
tls-auth /etc/openvpn/mondialu-ta.key 1
ping 10
ping-restart 60
up /etc/openvpn/mondialu-up.sh
down /etc/openvpn/mondialu-down.sh
client
resolv-retry infinite
nobind
user nobody
group nobody
persist-key
persist-tun
ns-cert-type server
comp-lzo

After we're connected setup the ipv6 address and default route.

mondialu-up.sh
#!/bin/bash
# script that is run on the client when it creates a tunnel to the remote OpenVPN server
IPV6BASE=feed:dead:beef:affe
V6NET=$(echo ${ifconfig_local} | awk -F. '{print $NF}')
/sbin/ip -6 addr add ${IPV6BASE}:${V6NET}::2/80 dev $dev
/sbin/ip route add ::/0 via ${IPV6BASE}:${V6NET}::1
exit 0

Tear everything down when we go down.

mondialu-down.sh
#!/bin/bash
IPV6BASE=feed:dead:beef:affe
V6NET=$(echo ${ifconfig_local} | awk -F. '{print $NF}')
sudo /sbin/ip -6 addr del ${IPV6BASE}:${V6NET}:2/80 dev $dev
sudo /sbin/ip route del ::/0 via ${IPV6BASE}:${V6NET}:1
exit 0

Share

Nov 30

Mail clients

We all use them. We all suffer under their inflexibilities and bugs. Some use them more some use them less. For those of us who use them for more than one or two emails a day a very important feature are filters.

However, there are some problems regarding those filters or more specifically, how those are created and where they are saved and executed.
Different MTA support different mail filter script formats on the server side. One of them more popular varieties are maildrop filter scripts. Those are very practical if you have static set of filters you need for your mail. Since these are saved and executed on the server you have your mail sorted for you in every client you use to connect to your account. These are like fire and forget rockets, you write them once and never touch them again.

So far so good, but every time you subscribe to a new mailing list you have to go back into you serverscript write new regular expressions to filter them. While this has worked just fine for a couple of decades now, maybe it is about time to improve this workflow.

Then there are the client side filters. Nearly every mailclient has some sort of filters or rules to sort mails. Quite similar to the possibilities we have on the serverside one can create filters based on the different fields in the mailheader. Of course if you only have one mailclient which you use, this is just fine and you won't understand my frustration at all. But as soon as you use one additional client like your phone or you computer at work, the limits of clientside filtering become obvious: they are client side. You either have to recreate your every filter on the second client or just wait till you get to your 'base' client again to have some order in your mailbox.

Enter sieve and managesieve: a possibility to manage server side scripts from client. Sounds promising, doesn't it? Well, one would hope you were able to create server side filters with sieve as easy as client side ones. Just click on the mail and create a filter based on some header field. Unfortunately that's not how ot works. You can edit the filters from you client alright, but all you get to do that is a lousy textfield???
At least on the server you can have syntax highlighting!

There are a couple of approaches to improve the whole mail business. For example I think google mail does a pretty good job. They even got rid of folders alltogether. Instead you just have tags. Mails can have multiple tags and aditionally to the usual header fields you can create filters based on these tags. And google mail actually tries to figure out which mails are important to you and puts them at the top of your inbox. There's a big negative to google mail though: you are not in control over your emails any more.

And I don't think this goes far enough with regards to the technology we have at our dispose today.

Even with the usage of buzzword technologies like NLP, automatic topic maps, etc there are many things that could be improved.
I would like to be able to define a folder where mailinglists should go to. New mailinglists should automatically be put into a new subfolder in there.
True, I could write that with maildrop scripts, but I shouldn't have to do that. The mailprogram/server should be able to do that for me. Same goes for people. When starting a conversation your mailclient should ask you after the x-th mail
'hey, would you like me to put mails from your new contact $joe into its own folder?'
That's not asking too much, is it?

With today's technologies it would be easy to sort your mails into folders/tag them based on the topic.[1,2,3]
You could tell your mailclient to show your all conversations you with Robert about your travel plans. Or something like ‘give me all emails from last years' X-Mas planning

As it stands today, email clients didn't evolve at all in the last 15 years! When I used The Bat! in 1996 it could do everything mailclients can do today. Sure we have nice themes now, but apart from that: nothing has changed :/

So what are we going to do about that? Lets create (yet another) mailclient!

Relevant RFCs:
RFC 5322
RFC 2045-RFC 2049
RFC 822 (1982) and RFC 2822 (2001)

[1] Email classification and summarization: A machine learning approach
by: Taiwo Ayodele, Rinat Khusainov, David Ndzi. In IET Conference on Wireless, Mobile and Sensor Networks, 2007. (CCWMSN07). IET Conference on (2007), pp. 805-808.  Key: citeulike:5637492
[2]Email Filtering: Machine Learning Techniques and an Implementation for the UNIX Pine Mail System by: Yu H. Chang   Key: citeulike:1379460
[3]Combining linguistic and machine learning techniques for email summarization
by: Smaranda Muresan, Evelyne Tzoukermann, Judith L. Klavans
In ConLL '01: Proceedings of the 2001 workshop on Computational Natural Language Learning (2001), pp. 1-8.
doi:10.3115/1117822.1117837
Key: citeulike:1422784

Share