Linode started to offer US$5 VMs and they are available in Tokyo (9ms ping as opposed to 122ms ping to California), so I could not resist to get another one and use it for some experimenting which I simply don’t dare to do on this very blog page (and my wife is using it for work too).
Goal
- 2 web servers serving web server stuff (a simple static index.html serves here)
- 3 virtual web addresses:
- first web server
- second web server
- round-robin web server which serves data from the first and second web server
- Everything with SSL without any warning from web browsers
Ingredients
- 1 VM with a public IP address
- 3 FQDNs pointing all to above IP address
- www1.qw2.org
- www3.qw2.org
- www4.qw2.org
- 2 web servers (www1, www3)
- 1 load-balancer (www4)
- 3 certificates for above FQDNs
Let’s Encrypt Certificates
I use acme.sh for my few certificate needs. This is how to get a new certificate issued:
./acme.sh --issue --dns dns_linode --dnssleep 1200 -d www4.qw2.org
This is using the DNS API from Linode (who hosts my DNS records). See more details here. It creates the required TXT record and removes it later again. I found that 1200 seconds wait time works. 900 does not always. I end up using 10 seconds, suspend the acme.sh command (shell ^Z), and use “dig -t TXT _acme-challenge.www4.qw2.org” until it returns some TXT record. Then continue the suspended acme.sh command.
You should then have a new directory www4.qw2.org in your acme.sh directory with those files:
harald@blue:~/.acme.sh$ ls -la www4.qw2.org/ total 36 drwxr-xr-x 2 harald users 4096 Feb 19 10:16 . drwx------ 17 harald users 4096 Feb 19 00:26 .. -rw-r--r-- 1 harald users 1647 Feb 19 10:16 ca.cer -rw-r--r-- 1 harald users 3436 Feb 19 10:16 fullchain.cer -rw-r--r-- 1 harald users 1789 Feb 19 10:16 www4.qw2.org.cer -rw-r--r-- 1 harald users 517 Feb 19 10:16 www4.qw2.org.conf -rw-r--r-- 1 harald users 936 Feb 19 00:26 www4.qw2.org.csr -rw-r--r-- 1 harald users 175 Feb 19 00:26 www4.qw2.org.csr.conf -rw-r--r-- 1 harald users 1675 Feb 19 00:26 www4.qw2.org.key
You’ll need the fullchain.cer and the private key www4.qw2.org.key later.
Repeat for www1 and www3 too.
Note that the secret key is world readable. the .acme.sh directory is therefore secured with 0700 permissions.
Setting up the Web Servers
Using lighttpd herte. The full directory structure:
harald@lintok1:~$ tree lighttpd lighttpd ├── 33100 │ ├── etc │ │ ├── lighttpd.conf │ │ ├── mime-types.conf │ │ ├── mod_cgi.conf │ │ ├── mod_fastcgi.conf │ │ ├── mod_fastcgi_fpm.conf │ │ └── www1.qw2.org │ │ ├── combined.pem │ │ └── fullchain.cer │ └── htdocs │ └── index.html ├── 33102 │ ├── etc │ │ ├── lighttpd.conf │ │ ├── mime-types.conf │ │ ├── mod_cgi.conf │ │ ├── mod_fastcgi.conf │ │ ├── mod_fastcgi_fpm.conf │ │ └── www3.qw2.org │ │ ├── combined.pem │ │ └── fullchain.cer │ └── htdocs │ └── index.html └── docker-compose.yml
Using the lighttpd.conf is simple and can be done in 5 or 10 minutes. The part for enabling https is this:
$SERVER["socket"] == ":443" {
ssl.engine = "enable"
ssl.pemfile = "/etc/lighttpd/www1.qw2.org/combined.pem"
ssl.ca-file = "/etc/lighttpd/www1.qw2.org/fullchain.cer"
}
fullchain.cer is the one you get from the Let’s Encrypt run. “combined.pem” is created via
cat fullchain.cer www1.qw2.org.key > combined.pem
Here the content of docker-compose.yml:
lighttpd-33100: image: sebp/lighttpd volumes: - /home/harald/lighttpd/33100/htdocs:/var/www/localhost/htdocs - /home/harald/lighttpd/33100/etc:/etc/lighttpd ports: - 33100:80 - 33101:443 restart: always lighttpd-33102: image: sebp/lighttpd volumes: - /home/harald/lighttpd/33102/htdocs:/var/www/localhost/htdocs - /home/harald/lighttpd/33102/etc:/etc/lighttpd ports: - 33102:80 - 33103:443 restart: always
To start those 2 web servers, use docker-compose:
docker-compose up
If you want to have a reboot automatically restart the service, then use do “docker-compose start” afterwards which installs a service.
To test, access: http://www1.qw2.org:33100, https://www1.qw2.org:33101, http://www3.qw2.org:33102, https://www3.qw2.org:33103
They all should work, and the https pages should find a proper security status (valid certificate, no name mismatch etc.).
Adding HAProxy
HAProxy (1.7.2 as of the time of writing) can be the SSL termination and forwarded traffic between the web server and HAProxy is unencrypted (resp. can be encrypted via another method), or HAProxy can simply forward traffic. Which one is preferred depends on the application. In my case it makes most sense to let HAProxy handle SSL.
First the full directory structure:
haproxy ├── docker-compose.yml └── etc ├── errors │ ├── 400.http │ ├── 403.http │ ├── 408.http │ ├── 500.http │ ├── 502.http │ ├── 503.http │ ├── 504.http │ └── README ├── haproxy.cfg └── ssl └── private ├── www1.qw2.org.pem ├── www3.qw2.org.pem └── www4.qw2.org.pem
The www{1,3}.qw2.org.pem were copied from the lighttpd files.
haproxy.cfg:
harald@lintok1:~/haproxy/etc$ cat haproxy.cfg global user nobody group users #daemon # Admin socket stats socket /var/run/haproxy.sock mode 600 level admin stats timeout 2m # Default SSL material locations #ca-base /usr/local/etc/haproxy/ssl/certs #crt-base /usr/local/etc/haproxy/ssl/private # Default ciphers to use on SSL-enabled listening sockets. # For more information, see ciphers(1SSL). tune.ssl.default-dh-param 2048 ssl-default-bind-options no-sslv3 no-tls-tickets ssl-default-bind-ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA -AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256 :kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES1 28-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA :DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256 -SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:A ES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CB C3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA ssl-default-server-options no-sslv3 no-tls-tickets ssl-default-server-ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-R SA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA2 56:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AE S128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-S HA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES2 56-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA :AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES- CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA defaults log global mode http option dontlognull timeout connect 5000 timeout client 50000 timeout server 50000 errorfile 400 /usr/local/etc/haproxy/errors/400.http errorfile 403 /usr/local/etc/haproxy/errors/403.http errorfile 408 /usr/local/etc/haproxy/errors/408.http errorfile 500 /usr/local/etc/haproxy/errors/500.http errorfile 502 /usr/local/etc/haproxy/errors/502.http errorfile 503 /usr/local/etc/haproxy/errors/503.http errorfile 504 /usr/local/etc/haproxy/errors/504.http stats enable stats uri /stats stats realm Haproxy\ Statistics stats auth admin:SOME_PASSWORD frontend http-in bind *:80 acl is_www1 hdr_end(host) -i www1.qw2.org acl is_www3 hdr_end(host) -i www3.qw2.org acl is_www4 hdr_end(host) -i www4.qw2.org use_backend www1 if is_www1 use_backend www3 if is_www3 use_backend www4 if is_www4 frontend https-in bind *:443 ssl crt /usr/local/etc/haproxy/ssl/private/ reqadd X-Forward-Proto:\ https acl is_www1 hdr_end(host) -i www1.qw2.org acl is_www3 hdr_end(host) -i www3.qw2.org acl is_www4 hdr_end(host) -i www4.qw2.org use_backend www1 if is_www1 use_backend www3 if is_www3 use_backend www4 if is_www4 backend www1 balance roundrobin option httpclose option forwardfor server s1 www1.qw2.org:33100 maxconn 32 backend www3 balance roundrobin option httpclose option forwardfor server s3 www3.qw2.org:33102 maxconn 32 backend www4 balance roundrobin option httpclose option forwardfor server s4-1 www1.qw2.org:33100 maxconn 32 server s4-3 www3.qw2.org:33102 maxconn 32 listen admin bind *:1936 stats enable stats admin if TRUE
Replace “SOME_PASSWORD” with an admin password for the admin user who can stop/start backends via the Web UI.
Here the docker-compose.yml file to start HAProxy:
harald@lintok1:~/haproxy$ cat docker-compose.yml haproxy: image: haproxy:1.7 volumes: - /home/harald/haproxy/etc:/usr/local/etc/haproxy ports: - 80:80 - 443:443 - 1936:1936 restart: always
To start haproxy, do:
docker-compose up
The Result
Now http://www1.qw2.org as well as https://www1.qw2.org works. No need for specific ports like 33100 or 33101 anymore. Same for www3.qw2.org. www4.qw2.org is a round-robin of www1 and www3, but it’s using the www4 certificate when using https. In all cases HAProxy terminates the SSL connections and it’s presenting the correct certificates.
Related: on http://www4.qw2.org:1936/haproxy?stats you can see the statistics of HAProxy.
Connecting it all all
Running 2 web servers plus the load-balancer with all of them internally connected and only the load-balancer visible on port 80 resp. 443 needs a new docker-compose.yml (changed to version 3 syntax) and a slight matching change haproxy.conf file:
harald@lintok1:~/three$ cat docker-compose.yml version: '3' services: lighttpd-33100: image: sebp/lighttpd volumes: - /home/harald/lighttpd/33100/htdocs:/var/www/localhost/htdocs - /home/harald/lighttpd/33100/etc:/etc/lighttpd expose: - 80 restart: always lighttpd-33102: image: sebp/lighttpd volumes: - /home/harald/lighttpd/33102/htdocs:/var/www/localhost/htdocs - /home/harald/lighttpd/33102/etc:/etc/lighttpd expose: - 80 restart: always haproxy: image: haproxy:1.7 volumes: - /home/harald/three/haproxy/etc:/usr/local/etc/haproxy ports: - 80:80 - 443:443 - 1936:1936 restart: always
No need for lighttpd to handle SSL anymore (no more port 443 needed to be exposed at all). Only the HAProxy is visible from outside. Small changes are needed on haproxy.conf, but only in the backend section:
[...] backend www1 balance roundrobin option httpclose option forwardfor server s1 lighttpd-33100:80 maxconn 32 backend www3 balance roundrobin option httpclose option forwardfor server s3 lighttpd-33102:80 maxconn 32 backend www4 balance roundrobin option httpclose option forwardfor server s4-1 lighttpd-33100:80 maxconn 32 server s4-3 lighttpd-33102:80 maxconn 32 [...]
And with “docker ps” we can see what’s happening under the hood of docker-compose:
harald@lintok1:~/three$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 742a2e5388f2 sebp/lighttpd "lighttpd -D -f /e..." 4 minutes ago Up 3 minutes 80/tcp three_lighttpd-33100_1 9d4c61e6c162 sebp/lighttpd "lighttpd -D -f /e..." 4 minutes ago Up 3 minutes 80/tcp three_lighttpd-33102_1 2e41dfa26ac9 haproxy:1.7 "/docker-entrypoin..." 4 minutes ago Up 3 minutes 0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp, 0.0.0.0:1936->1936/tcp three_haproxy_1
]]>
However HTTPS also supports virtual HTTPS servers: SNI does that.
And here is how to use it with HAProxy:
frontend https-in bind *:443 ssl crt /etc/haproxy/ssl/private/ reqadd X-Forward-Proto:\ https acl is_site1 hdr_end(host) -i www1.qw2.org acl is_site2 hdr_end(host) -i www2.qw2.org use_backend site1 if is_site1 use_backend site2 if is_site2
All the magic is in the bind line where a directory with PEM certificates (concat of fullchain.cer and the key)
Now you can have https for everything and HAProxy will handle all the secure connectivity for you.
]]>One missing feature however was that DHCP leses did not get a DNS entry. The simple workaround was that stuff which should get DNS gets a static IP. Anything else doesn’t and thus is not reachable by DNS. Was not a big deal until I used Vagrant which can build VMs (via VirtualBox). Now I got plenty VMs which I simply bridge on the normal LAN. But in order to connect to them outside of “vagrant ssh nodeX”, I needed to have their IP. Vagrant can tell me, as can the VM itself when I connect via “vagrant ssh”, but all this is way more complex than simply using DNS. dnsmasq does that automatically, but not the DHCP/DNS combo on RouterOS.
Scripts to the rescue!
https://www.tolaris.com/2014/09/27/synchronising-dhcp-and-dns-on-mikrotik-routers/ has a nice one which does what it’s supposed to do. Relying on the TTL to be different from static DNS entries, it’ll create or delete DNS records which according to DHCP leases should or should not exist.
One important hint: you need to allow the script to read/write “things”. And the scheduler when running the script.
TTL for DHCP is set to 15min. TTL for static enteries is 1d. The script runs every 5min.
]]>Everyone knows, port 53 is DNS. Why would we or a virus try to connect port 53 on a non-server?
I checked all computers (the Windows machines was a natural first suspect), but all was clean. And then it dawned me: DNS Amplification attack! Using our router.
A quick check on the router showed more activity than normal, so it was confirmed that the router is the culprit.
The NAT connection table then promptly showed about 2000 connections with more and more being created while old ones were closed due to inactivity.
How to fix this? Disable remote DNS requests! Except remote is anything non-local to the router which also disabled the internal network from using DNS as all machines in our LAN use our router as DNS server (resp. relay).
The next attempt was better: set up the firewall to drop incoming DNS requests which come from the ppp interfaces.
Now I got about 50 active connections again (that’s normal), no odd DNS requests, and 
about 500 packets per second are being dropped. That accumulates quite fast. 280k packets dropped while writing this article.
The magic fix looks like this:
/ip firewall filter add chain=input action=drop protocol=udp in-interface=all-ppp dst-port=53 log=yes log-prefix=Ext-Incoming-DNS
That was interesting. Relatively easy to defeat. I’m surprised this is not configured by default, but then, I have a rather non-user-oriented router where it’s expected that the admin knows what he’s doing…
I’ll have to look a bit more into security of the router in regards to DoS attacks and logging and notifications for unusual traffic.
Wanted to put a VPN gateway into a Docker container. Turned out to be difficult since the container needs to accept ESP traffic for IPSec, which I could not make work.
However running a SoftEther VPN server turns out to be easier than expected: Have the binaries, and a vpn_server.config file, and off you go. To create the config file, use the Windows management utility.
On the client side it’s rather simple. Windows client software is neat and straightforward. Linux is not much harder:
# Download softether-vpnclient-v4.19-9599-beta-2015.10.19-linux-arm_eabi-32bit.tar.gz to e.g. /var/tmp/ cd /usr tar xfv /var/tmp/ softether-vpnclient-v4.19-9599-beta-2015.10.19-linux-arm_eabi-32bit.tar.gz cd vpnclient make i_read_and_agree_the_license_agreement ./vpnclient start ./vpncmd 2 (Management of VPN Client) ENTER (picks localhost) NicCreate VIRTUALNIC (e.g. box2) AccountCreate ACCOUNTNAME (e.g. box2) vpn.domain.org:443 (VPN Server Host Name and Port Number) VIRTUALHUBNAME (e.g. Box2Hub) USERNAME (e.g. harald) box2 (Virtual NIC) # AccountPasswordSet ACCOUNTNAME PASSWORD (password for USERNAME) PASSWORD (repeat) standard (standard or Radius) # # Autostart: AccountStartupSet ACCOUNTNAME # Connect: AccountConnect ACCOUNTNAME # Check AccountStatusGet ACCOUNTNAME
And that’s it. It’ll create a virtual NIC vpn_box2 and whenever you start vpnclient, it’ll create it and connect.
E.g. have this in /etc/rc.local:
( /usr/bin/vpnclient start ; sleep 10 ; ifconfig vpn_box2 192.168.30.51 netmask 255.255.255.0 up ) &
or alternatively if you can take any IP address:
( /usr/vpnclient/vpnclient start ; sleep 10 ; dhclient vpn_box2 ) &
In case of slow connection/computers, increase the 10s delay to more. I use 20s for my AllWinner A20 CPUs.
]]>
Here was a great start and given that I did not know Lua a lot (and I am sure I don’t still), it was a nice little challenge to expand the example to include all 6 LEDs.
Here the result:
myled={ 4, 3, 2, 1, 5, 0, 6, 7, 8 }
mystate={}
start_init = function()
local i
for i=1,6 do
gpio.mode(myled[i], gpio.OUTPUT)
gpio.write(myled[i],gpio.HIGH)
mystate[i]=0
end
end
sendFileContents = function(conn, filename)
if file.open(filename, "r") then
--conn:send(responseHeader("200 OK","text/html"))
repeat
local line=file.readline()
if line then
conn:send(line)
end
until not line
file.close()
else
conn:send(responseHeader("404 Not Found","text/html"))
conn:send("Page not found")
end
end
responseHeader = function(code, type)
return "HTTP/1.1 " .. code .. "\nConnection: close\nServer: nunu-Luaweb\nContent-Type: " .. type .. "\n\n";
end
httpserver = function ()
start_init();
srv=net.createServer(net.TCP)
srv:listen(80,function(conn)
conn:on("receive",function(conn,request)
conn:send(responseHeader("200 OK","text/html"));
fflag, findex, pin=string.find(request, "gpio=(%d+)")
pin=tonumber(pin)
if fflag and pin>=1 and pin<=6 then
print("Changing pin "..pin.." to ")
if mystate[pin]==0 then
mystate[pin]=1
gpio.write(myled[pin], gpio.LOW)
print("on\n")
else
mystate[pin]=0
gpio.write(myled[pin],gpio.HIGH)
print("off\n")
end
else
sendFileContents(conn,"schead.htm")
local i
for i=1,6 do
if mystate[i]==0 then
preset=""
else
preset="checked=\"checked\""
end
conn:send("<div><input type=\"checkbox\" id=\"chbox"..i.."\" name=\"chbox"..i.."\" class=\"switch\" onclick=\"loadXMLDoc("..i..")\" "..preset.." />")
conn:send("<label for=\"chbox"..i.."\">GPIO "..i.."</label></div>\n")
end
conn:send("</div>")
end
print(request);
end)
conn:on("sent",function(conn)
conn:close()
conn = nil
end)
end)
end
httpserver()
Note:
- I use only the 6 red LEDs on the dev board I have
- I had to shorten the text sent to the web client from “checkbox2” to “chbox2” as otherwise the last characters of those 6 lines were missing. That showed when some LEDs were on and I reloaded the page. Then toggle 6 went missing. Thus don’t send too much too fast.
]]>
The Internet of Things was for the longest time limited to bigger things. Costs of US$100 and more for a IP connected device was a given.
Arduino boards like this Ethernet Shield with a W5200 chip still needed a separate CPU. And it was not wireless, so add in a cable and a fraction of a switch. Newer possibilities are Raspberry Pi + USB WLAN stick (<US$40). Those were a bit expensive and quite large if all you want is switch on/off something small like a lamp.
Then came solutions like Spark Core which were relatively cheap (<US$40) and small. Slowly getting there.
And then the ESP8266 showed up, making most other solutions oversized and overpriced: About US$3 for the naked module (ESP-12) and US$11 for a small dev module. And you can program it in C or Lua or JavaScript. And not only is it cheap and quite capable, but it is also small, low-power and it’s easy to work with and connect it to various interfaces: GPIO, I2C, SPI, RS232, PWM etc.
Here an example of the blinking LED in Lua:
gpio.mode(4, gpio.OUTPUT) led4=0 function switchled4() if led4==0 then gpio.write(4, gpio.LOW) led4=1 else gpio.write(4, gpio.HIGH) led4=0 end end tmr.alarm(0,1000,1,switchled4)
This leds the LED connected to GPIO4 (internal numbering, just like Arduino does) blink. And here a link to an example which uses a web page with AJAX to toggle 2 LEDs.
All in all, there is no reason to NOT allow pretty much anything to be connected to your WiFi network.
]]>
It’s actually very easy too
Server side
Debian server: install some packges:
aptitude install pptpd
/etc/pptpd.conf (I removed all comments here):
option /etc/ppp/pptpd-options logwtmp localip 192.168.31.1 remoteip 192.168.31.10-249
/etc/ppp/pptpd-options (again, no comments):
name SERVERNAME refuse-pap refuse-chap refuse-mschap require-mschap-v2 require-mppe-128 proxyarp nodefaultroute lock nobsdcomp noipx mtu 1490 mru 1490 ipcp-accept-remote netmask 255.255.255.0
Add this to /etc/rc.local:
/sbin/iptables-restore </etc/iptables.save
Setting up routing and firewall:
iptables -A FORWARD -s 192.168.31.0/24 -d 192.168.31.0/24 -j ACCEPT iptables -A FORWARD -s 192.168.31.0/24 -j REJECT
Edit /etc/sysctl.conf to enable IP fording:
net.ipv4.ip_forward=1
Enable sysctl.conf changes:
sysctl -p
Edit /etc/ppp/chap.secrets to have all accounts, e.g.:
username1<TAB>*<TAB>password<TAB>*
Client side
Debian: install some packages
aptitude install pptp-linux
Create /etc/ppp/peers/BoxPPTP (BoxPPTP is the name of the connection):
pty "pptp PPTPSERVERNAME --nolaunchpppd" name harald remotename BoxPPTP require-mppe-128 file /etc/ppp/options.pptp ipparam BoxPPTP 192.168.31.10:
192.168.31.10 is the IP the client wants to have.
/etc/ppp/options.pptp:
lock noauth refuse-pap refuse-eap refuse-chap refuse-mschap nobsdcomp nodeflate
Add your account in /etc/ppp/chap-secrets:
username1<TAB>BoxPPTP<TAB>password<TAB>*
Add this to /etc/network/interfaces:
auto ppp0 iface ppp0 inet ppp provider BoxPPTP post-up sleep 2 ; route add -net 192.168.31.0 netmask 255.255.255.0 gw 192.168.31.1
To enable the PPTP connection, do:
ifup ppp0
Check via:
# ip addr list ppp0 20: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1486 qdisc pfifo_fast state UNKNOWN qlen 3 link/ppp inet 192.168.31.11 peer 192.168.31.1/32 scope global ppp0 # ip route list default via 192.168.11.1 dev eth0 192.168.11.0/24 dev eth0 proto kernel scope link src 192.168.11.36 192.168.31.0/24 via 192.168.31.1 dev ppp0 192.168.31.1 dev ppp0 proto kernel scope link src 192.168.31.11
At this point you can ping the PPTP server (192.168.31.1 in this case) as well as all other clients as long as they are not firewalled.
]]>
Finally got a small NAS. Although it was tempting to get a bigger/faster one with 5 or 4 disk slots and a fast CPU, it’s way overkill for my purpose, so in the end, I went for a small DS212j plus a (for now) 3TB disk.
It’s plenty fast (75MB/s read via NFS), the GUI is awesome, the capabilities more than sufficient. It has some kinks though:
- The OS is on the disk and not in flash memory.
- If you have 2 different size disks, then if you create a mirrored volume, the rest of the space goes unused instead of being able to use it as a non-mirrored volume.
- Volumes always take full disks (or what is left after the OS is copied on them)
- To enable NFS, you need to first enable it, and then create shares (which are usually for Samba shares), and there enable NFS sharing too.
- To enable home directories, click on the user modules and click there on “User Home” and enable it and say which volume to use.
- Disk groups names are hardcoded: Disk group 1, Disk group 2 etc.
- Volume names are hardcoded: Volume 1, Volume 2 etc. They map to mount points called /volume1, /volume2 etc.
- The media server does not ask for the location of files. It defines it to be on a volume you pick.
If you have only 2 disks, do yourself a favor and get 2 of identical size and use a RAID-1 (or their hybrid volumes). Alternatively expect no mirroring whatsoever. If you have more disks (4 would be a good start), then this is much less of a problem.
]]>
I have not used my GLANTANK for quite a while. Now it has a new purpose: I use as a server for lsync. lsyncd is what I was looking for for a while: it synchronizes directories a la rsync (it’s actually using rsync for that), but it is using the inotify feature of the Linux kernel which informs a process that a file has changed. So instead of scanning every (say) 1h thousand of files, it copies the ones which are modified much sooner and does not need a full scan of all files except on startup.
The old Debian installation was outdated, so I wanted to re-install Debian Linux on the GLANTANK first. I used the same instructions in the past and it worked as expected. So I was hopeful this time too. ssh never started up though.
The only way to see something happening then is to use a serial console. See also here for some pictures. Pins are 1:3.3V, 2:RxD, 3:TxD, 4:GND. 115200 bps and 8N1.
And the problem is that the latest kernel 2.6.32-5-iop32x has no driver for the GLANTANK disk interface, and that stops the installation process. The fix is on the Debian bug list and that solves it.
Next problem are the not-so-quiet fans. There’s a program to control them called fanctld. Needs kernel header files and gcc-4.3 to create a working fandrv.ko kernel module.
Update: Plugging in and out of disks with a cable which is soldered to the mainboard is a bad idea: the cable broke and no disk worked afterwards. Well, it was fun while it lasted. Which was until now.
]]>