Synology rsync and non standard ports

2016-03-09  |   |  infrastructure  

Recently running rsync to my Synology diskstation stopped working. I had just changed my default SSH port to a non standard one. Learn how to fix it.

Synology recommends to change the default SSH port to a non standard one. What they forgot to tell you is that it will break your ability to rsync into the machine. Here is a way to fix it.

The workaround way

One way to fix it is to use the --rsync-path=/usr/syno/bin/rsync option.

rsync -avz --rsync-path=/usr/syno/bin/rsync from-dir/ synology:/volume1/Backups/to-dir

Since you use a non standard SSH port, make sure to also update your .ssh/config file to point to the right one.

Host synology
    User alice
    Hostname # my synology IP
    Port 911 # my new SSH port and a nice car

That works around the Synology quirk but it requires to update all your rsync scripts.

The proper way

Log to the web management console and open the Backup & Replication application. Select Backup Services and update the SSH encryption port to match your new SSH port, in my example 911. Note that for some reason the UI forbids certain port numbers. Make sure to use a non restricted number for your SSH port in the first place or use trial and error.

The SSH port can be changed in the Control panel, Terminal & SNMP.

Moving to HTTPS

2015-05-09  |   |  infrastructure  

I have decided to move this website to HTTPS. Let me know if you see anything fishy, cannot access it or if the RSS feed no longer updates. Why? With my country's government going completely stupid, I decided to play the nut game, I can be pretty stupid too.

In its infinite wisdom, the French government has decided to enable mass surveillance of the French people without oversight of the justice branch. Yes I know WTF?!

Anyways, in order to make things simpler for them, I have decided to move all of my web properties behind HTTPS (HTTP over TLS). Do I have anything to hide? Nope, I just want to increase universe entropy and cracking our communication a bit more challenging.

My certificate fingerprints are:

  • SHA1: 15 3E 2E 67 39 28 20 28 6E F6 CF F5 E1 92 AB 07 72 32 72 90
  • MD5: 0B 2D 49 61 DE EA E1 D7 11 92 BA 3D 4F BD 73 E2

If you see something else then, you are being intercepted. Read more on secure connection fingerprints.

SPF for dummies - how to fight spams

2015-03-26  |   |  infrastructure  

In this post, you will learn everything you need about SPF (Sender Policy Framework), what it means for your emails and how / if to set it up for your domains.

What is it for and should I care?

This is a standard that helps reduce spam. Each domain lists in one DNS record the list of servers that are allowed to send emails for that domain. So when an email provider like Gmail sees an email sent from an address but coming from a server not listed in the SPF record, it knows it is likely a spam.

Conversely, it is important to set such a record to avoid your emails to be considered spam. More and more email providers consider domains without SPF record as more suspicious than others. Even if you domain does not send emails, you should set a SPF record, this will prevent spammers from faking emails from you.

How does it work ?

As owner of a given domain, you will tell the world which servers you will send emails from. That is typically your SMTP server.

In practice, this is a TXT entry in the DNS records of your domain. Something like

"v=spf1 a ip4: -all"

v=spf1 is the protocol, all entries start with this.

a or generally says that all IPs listed in the DNS A record of the domain should be able to send emails for that domain. If the domain is not specified (a), then it is the domain for which the TXT DNS record lives.

ip4: means that IP is allowed to send emails for your domain. You can assign ranges as well. Likewise, there is an ip6 syntax. means that you should consider the SPF rules stored in the DNS entries of This is very useful if you use Google Apps / Gmail or send emails from another domain's SMTP server. Rules can be composed, so you can have explicit ips, a and includes in the same SPF entry.

There are also mx and ptr entries but I won't go into details.

Finally, you need to decide what to do when the rules don't match. That's where the all mechanism comes into play:

  • -all means that servers that do not pass the rules should be considered spammers
  • ~all means that servers that do not pass the rules should be considered spammers but we are not 100% sure so let them pass but be suspicious
  • ?all means that servers that do not pass the rules should be considered neutral (i.e. they may be legit or not)

If your list is exhaustive, use -all to lock things down. If people sending emails from your domain might use their own SMTP server, use ?all. ~all is for chickens ;)

You can get a formal description of all the options at

You can lookup the SPF entries for any domain by typing

nslookup -q=TXT

This is useful before you add an include clause.

A few concrete examples

My domain never sends any email: "v=spf1 -all".

I use Gmail / Google Apps to send emails from that domain: "v=spf1 -all".

I use Gmail and Red Hat's SMTP: "v=spf1 -all".

I use the server hosting and Red Hat's SMTP: "v=spf1 a -all" (this is a short hand for "v=spf1 -all"

People sending email as use various SMTP servers but for sure and it's corresponding IPv6 2001:db8::df4:cd23 and's SMTP servers: "v=spf1 ip4: ip6:2001:db8::df4:cd23 ?all"

A note on TXT DNS entry, to use (I think) the bind syntax, here is how it looks like

# let's say it's the DNS zone of
# some domain
@ 10800 IN A
# some subdomains
awesome 10800 IN CNAME
blog 10800 IN CNAME
# looks like these guys use Google Mail
@ 10800 IN MX 10
awesome 10800 IN MX 10

# Here is our subject
# you need one entry per domain and subdomain sending emails
@ 10800 IN TXT "v=spf1 a -all"
awesome 10800 IN TXT "v=spf1 a -all"
# blog never sends emails
blog 10800 IN TXT "v=spf1 -all"

Conclusion and a few recommendations

I prefer domain names over IPs so I use a or mx entries. As much as I can, I use include and delegate the list to the real guys.

Google and others use special subdomains like to host their SPF rules. This is useful to separate different ruleset but bind them together in your primary domain via an include rule. If you are one of them, you probably don't need my blog entry in the first place :)

Remember that servers now have IPv6 addresses and that Google and other have already IPv6 infrastructures in place. Don't forget them, I had some emails denied because I was missing it and my server communicated with Google from an IPv6.

My take out is simple: if you own a domain and send emails, add a SPF entry. It's relatively simple and the examples I gave you should get you a long way already.

PS: I am relatively new to this domain, feel free to correct me in the comments, if I made a mistake.

Name: Emmanuel Bernard
Bio tags: French, Open Source actor, Hibernate, (No)SQL, JCP, JBoss, Snowboard, Economy
Employer: JBoss by Red Hat
Resume: LinkedIn
Team blog:
Personal blog: No relation to
Microblog: Twitter, Google+
Geoloc: Paris, France