Posts tagged dns

powershell ip reverse resolution
posted on 2017-01-27 15:22

A quick script to do reverse resolution of a textfile containing ips called ips.txt located in the same directory as the the file you put this content into:

$erroractionpreference = 'silentlycontinue'
get-content .\ips.txt | foreach-object {
        $resolvedip = [System.Net.Dns]::gethostentry($_).hostname
        echo "$_        : $resolvedip"
}

Save and execute. Might have some rough edges, this did not get much testing.

DNS: resolution and reverse resolution script
posted on 2016-05-21 20:54

This is a quick-and-dirty for loop for checking a list of dns A resource records using dig. CNAME's are not handled like they should, thus are printed not in the same line, so this can not be used for being parsed without first having a look at the output and curating it first, if these are in use.

for i in sjas.de blog.sjas.de; do echo -n $'\e[33;1m'$i$'\e[0m '; TEMP=`dig +short $i`; echo -n "$TEMP "; TEMP=`dig -x $TEMP +short`; echo ${TEMP%.}; done | column -t

Instead of editing the for-loop, it might be helpful using a heredoc instead:

echo; cat << EOF | while read i; do echo -n $'\e[33;1m'$i$'\e[0m '; TEMP=`dig +short $i`; echo -n "$TEMP "; TEMP=`dig -x $TEMP +short`; echo ${TEMP%.}; done | column -t; echo

Paste this into the shell, followed by a paste of lines of the domains you want, and type EOF afterwards.

Example:

sjas@sjas:~/blog$ echo; cat << EOF | while read i; do echo -n $'\e[33;1m'$i$'\e[0m '; TEMP=`dig +short $i`; echo -n "$TEMP "; TEMP=`dig -x $TEMP +short`; echo ${TEMP%.}; done | column -t; echo
sjas.de
ix.de
asdf.de
EOF

sjas.de  78.47.176.149  static.149.176.47.78.clients.your-server.de
ix.de    193.99.144.80  redirector.heise.de
asdf.de  80.237.132.85  wp078.webpack.hosteurope.de

sjas@sjas:~/blog$ 
Shopware: temp domain
posted on 2016-02-26 09:59:32

When migrating a shopware installation or creating a testing environment, the shop has to run under a different URL.

As of version 5.1.3 this is done like this: (Most of this is self explanatory, but still...)

  • Set up the virtual host in your webserver.
  • Make sure you have your dns entries set up accordingly.
  • Change the .htaccess, so the rewrite rule will lead to your temporal domain.
  • Change two fields in the shops database, where the URL is set, too.

On the last two points, heres some more info how things should look like for my example WWW.MYDOMAIN.DE.

.htaccess:

RewriteCond %{HTTP_HOST} ^MYDOMAIN.DE [NC]
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://WWW.MYDOMAIN.DE/$1 [R,L]

Database: (see lines 8 host and 11 hosts, 5 name should not matter )

 1  mysql> SELECT * FROM s_core_shops\G
 2  *************************** 1. row ***************************
 3                    id: 1
 4               main_id: NULL
 5                  name: WWW.MYDOMAIN.DE
 6                 title: NULL
 7              position: 1
 8                  host: WWW.MYDOMAIN.DE
 9             base_path: NULL
10              base_url: NULL
11                 hosts: WWW.MYDOMAIN.DE
12                secure: 1
13           secure_host: NULL
14      secure_base_path: NULL
15           template_id: 33
16  document_template_id: 22
17           category_id: 3
18             locale_id: 1
19           currency_id: 1
20     customer_group_id: 1
21           fallback_id: NULL
22        customer_scope: 0
23               default: 1
24                active: 1
25         always_secure: 1
26  *************************** 2. row ***************************

...

Basically, you have to change the fields host and hosts in the s_core_shops table to your temp domain URL.

openvpn: dns pushed on linux
posted on 2016-02-14 22:45:53

To have openvpn push its DNS server successfully through the tunnel, you have to have these settings in your <filename>.ovpn file:

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

and have the package resolvconf installed:

apt install resolvconf

That way your dns servers get exhanged in /etc/resolv.conf everytime the tunnel get established or disconnected.

This was only tested on debian.

Linux: website migration guide
posted on 2015-06-19 19:53:32

Migrating a website can be a tedious task, if you have problems keeping several things at once inside your head. This aims to solve this problem by presenting some proper guidelines.

Here we have a standard dynamic website with a mysql backend, served through an apache httpd.

For other databases/webservers the steps may differ in particular, but essentially this is the same theory everytime.

Mailmigration will as of now not be a part of this here, since it's gonna be long enough anyway.

Read this completely prior, as alternative ways are suggested sometimes.

preparations

This part is almost the most important, actual copying is usually not that hard if you know what you are doing. It's often harder to remember everything.

Before we start, the server can serve data of three kinds which are handled all the same way.

web data, just copy the website code
database, copy the database dump file
emails, copy the mailfiles

The server is accessed via the globally available...:

dns

Basically these are the things you have to copy/adjust so things will go smooth.

preparations

open questions

Putting most of these questions plus the answers to them into a spreadsheed is not the worst idea. Maybe I will come up with a shell one-liner to create a .csv later.

Also it is helpful if you are able to do FXP (transfer files from one host directly to the other, without temporary saving the data/files locally), if you do not have SSH access.

  • server access via ssh is possible?

  • ssh works via key? or password only?

  • root account? (a lot of this guide assumes root privileges, I might have missed points there are no alternatives)

  • if not, do you have all necessary account credentials for all folders etc.?

  • DO THESE WORK?

  • if no ssh, do you have ftp credentials?

  • do the credentials actually work?

  • do you get a database dump you can transfer? (If you cannot access the server, you can't make a dump.)

  • are the folder accurately named?

  • how BIG is the webfolder? (so how long will copying take?)

  • which database management system is used? (i.e. mysql or postgres)

  • database credentials for it are?

  • what is the database the site is using actually called?

  • just how BIG is the database? (and so how long will copying take?)

  • what domains are pointing to the server?

  • are these actually active?

  • and can you change the DNS RR?

  • what are the DNS TTL times?

  • is mailing configured?

  • don't forget the DNS MX RR/RR's while at the last point

DNS: aquiring information active resource records

For finding out about the dns, if you have several virtual hosts on the same machine, try grepping them all there.

When having an apache, grep all vhost files for ServerName and ServerAlias. Here's a kind-of snippet, which will work if your apache vhost configs are in default locations and indented:

\grep -e '^\s\+Server' /etc/apache2/sites-enabled/*

This shows only active sites, check sites-available if you have to migrate sites which are currently turned off, too.

The resulting list, if sanitized, can be piped on the shell and used with something like host/nslookup/echo + dig +short, to easily check which domains are still running. Check all the records, not just the A/AAAA (quad-A is ipv4, single-A is ipv4) records, also MX and whatever is set. If the exit code is non-zero, no dns anymore and less work for you. Providing a script here would not help much, since you should know what you are doing here anyway and it would most likely not help you much.

and maybe prepare the webserver, too

In case the apache config is, lets say, 'adventurous', do apache2ctl -S (Debian/Ubuntu) or httpd -S to see which domains are hosted, and in which file these are defined. Then search there for ServerName/ServerAlias directives.

If the webserver happens to have all vhosts defined in one huge file (which ist just... very not great), remove the configuration and place them into a separated file. In Debian-based Linuces you can use a2ensite <vhost-config-filename> / a2dissite <vhost-config-filename> to enable/disable single websites easily. On Redhat-based ones you create the symlinks to the configfolder apache is configured to load manually and delete them also by hand. (This isn't any different from what a2en/dissite do.) All this only for the sites you want to migrate.

Of course, you can just comment out the information on your vhosts from the config, but just... don't.

For other webservers all this is different, of course, but you get the idea.

DNS: get the domains and the website together, information-wise

Refer to the website via its main link. (apache ServerName from above.) But make sure to note all other aliases there, too. (apache ServerAlias from above.) Since you can only migrate one site after another, this helps to keep track. Write all this down, each alias in another row. Maybe put the inactive ones into an extra column there, too. Could be that these should be prolonged again, or were incorrectly set. (I.e. it did not point to the webserver when you checked.)

Write the set TTL into the next column, along with the current date. (Usually TTL is 86400, which means 24 hours, which is exactly how long it will take until your change to 1800 seconds becomes finally active. If the TTL was longer than 86400 for whatever reason, note that into your list, too!)

DNS: lower TTL the day before the migration

After having created a list and checked which domains are currently active, set the default TTL time to 1800. (Just don't go below, 30 mins are short while you do the migration. Also the registrar might prefer you not to.)

DNS: plan b in case you have dozens of websites to migrate

If you have A LOT of websites that should go from one server to the next, try migrating and testing everything (via entries in the hosts file). Then switch the ip's of the servers with each other. That way no dns changes are needed (except if you have dead domains), because this shit can become tedious, too.

TBD / todo

Nothing more here now, until i am motivated again to write more stuff up.

DNS: subzone delegation for a subdomain for a dynamic ip
posted on 2015-05-01 01:16:37

As a sideproject I wanted a dynamical DNS, since seemingly all the free products out there all went out of business, started to charge money or have started having other bad habits like coercing you to periodically log into the service or your domain was turned off.

Since I already had a server plus a domain, an own DNS server was a nice idea. But changing the authorized nameserver for a domain leads to the need of having to update the settings of the domain at the registrar, which I did not want:

  • The primary DNS server for the main domain should stay with my hoster.

This is due to the server being a playground, and if something broke and the nameserver daemon would run on the server, the DNS would be out of order. Also I was kind of lazy to get my hoster to change the settings, and where would the fun be in the easy way anyway?

After looking around some time, I found out about subzone delegation, which needs some additional RR's/resource records in the config of the main domain, but no changes to the DNS Server which is authorative for it. Ain't that an idea? Just exactly what I needed.

So here a little howto on how to implement this, on an external CentOS server with a fixed IP, a Fritzbox router where a raspberry pi is behind, and a hosted domain at an ISP / Internet Service Provider. The raspberry is running a raspbian install as an OS / Operating System. Strictly speaking, the raspberry is not really necessary, but better 'for reasons'.

Example values in the following are:

  • mydomain.de for the domain, pointing to 10.10.10.1.
  • dyn.mydomain.de is the subzone, which will serve the dynamically changing ip.
  • the authorative nameserver for the main domain is at 10.20.20.1
  • 10.10.10.1, where the main domain is pointed at, will also be the secondary DNS server which serves the dynamic domain as subzone of the main domain.
  • the mailaddress which is usually used, is called email@domain.tld

The dynamic ip will be denoted as 999.999.999.999 in the following.

change RR's of main domain at your hoster

Add these two:

dyn.mydomain.de.             IN NS      ns.dyn.mydomain.de.
ns.dyn.mydomain.de.          IN A       10.10.10.1

Don't forget to increment the serial number (the first in the list of numbers after the line of the SOA definition), else your setting will not become public!

If you are lucky, you can add these two lines in a web interface that your domain hoster provides, else you have to tell the guys over there to change the settings for you.

install dns server on remote machine

On CentOS the bind9 dns server is referred as named, 'name daemon`.

yum install named -y

domain configuration of subdomain, on remote CentOS server

/var/named/master.dyn.mydomain.de:

; public zone master file
$TTL 1800
; provides minimal public visibility of external services
dyn.mydomain.de.  IN      SOA   ns.dyn.mydomain.de. email.domain.tld. (
                              2015042800    ; se = serial number
                              10800         ; ref = refresh
                              1800          ; ret = update retry
                              604800        ; ex = expiry
                              1800          ; min = minimum
                              )

dyn.mydomain.de.        IN NS      ns.dyn.mydomain.de.
;; next line is then domain name of the name server for mydomain.de
;; it also should have a FQDN, so you don't just pass the IP, but do a second A RR to the NS RR
dyn.mydomain.de.        IN NS      ns.mydomain-or-else.de.

ns.dyn.mydomain.de.     IN  A       10.10.10.1
ns.mydomain-or-else.de. IN  A       10.20.20.1

dyn.mydomain.de.        IN  A       999.999.999.999

Also, doing changes here, you have to increment the serial as well so that the changes become known. Usually this number is YYYYMMDDSS if I remember correctly. Does not matter, it just has to be bigger after each change you do to it.

On the values of the other numbers following the serial, I don't exactly know what they do. I just remember someone telling me that the RIPE would not be amused if TTL's are lower than 1800s (0,5h), so all these are bigger than that.

At the line defining the SOA RR / start of authority resource record the second

Never forget the dots at the end of domain names when specifying the absolute names (not just the string of hot the subdomain is called), these denote the end of the current domain name. Else the current domain name will be appended and you will have some fun time figuring out why things do not work. NOT.

bind configuration for the subzone name server

On the external server, make sure bind listens on public interface for DNS requests, so bind the listen port also to the NIC with the external ip:

/etc/named.conf

options {
        listen-on port 53 { 127.0.0.1; 10.10.10.1; };

        ...
}

Also add the zone entry for your subzone:

zone "dyn.mydomain.de" IN {
        type master;
        file "master.dyn.mydomain.de";
        allow-query { any; };
};

On a sidenote, the dnsroot folder is at /var/named/, so you just pass the file or folders above to the file directive in the config, as shown above.

Enable logging:

logging {
        channel default_debug {
                file "data/named.run";
                severity dynamic;
        };
};

And also create the file if it does not exist:

touch /var/named/data/named.run
chown -R named.named /var/named/data

With this configuration in place and a restart of the server, you already should be able to dig dyn.mydomain.de / nslookup dyn.mydomain.de / host dyn.mydomain.de. dig, the 'domain information groper' is the nicest one since it provides the most output, as long as you understand what you are doing. If you do, you know all this anyway.

troubleshooting

  • Do you have a firewall in place?
  • Port 53 is open?
  • What does tail -f /var/named/data/named.run tell you, right when you connect?
  • If you have fail2ban, is your ip currently banned?
  • Try a tcpdump on the external server on the IF / interface which holds the external ip.
  • Have a look at the log where the dropped packets are logged on your system, if there's anything like that.

Try a debugging script like this: (chmod a+x on the file may help.)

#!/bin/bash

## check if domains are globally available
## you can also ask the google DNS via @8.8.8.8
## should print both ips, else you have something broken in your configuration...
## ... or it takes the internet time, to get to know your DNS, maximum 30 minutes due to TTL 1800
echo GLOBAL
dig mydomain.de +short
echo dyn
dig dyn.mydomain.de +short
echo

## check if domains are available via your domainhosters nameserver
## this should only serve the main domain
echo DOMAIN NS
dig @ns1.your-server.de mydomain.de +short
echo dyn
dig @ns1.your-server.de dyn.mydomain.de +short
echo

## check if domains are available via your own nameserver
## this should only serve your subdomain in our setup
echo OWN NS
dig @mydomain.de mydomain.de +short
echo dyn
dig @mydomain.de dyn.mydomain.de +short

If all works as expected, congratulations. Else good luck troubleshooting this.

What is still missing now is the configuration so that the DNS will updated once your dynamic ip changes.

update DNS for the dynamic ip once it has changed in theory

Every 24 hours I have a forced disconnect from my telecommunications company, thats when my home ip changes. On the router a scheduled reconnect can be set so this happens at a known time, I set it to 4am.

Now on the update of the DNS for the dynamic domain:
This has to be done from a machine which is behind your router, or from your router. Usually you do not have a router with a fully fledged operating system, or you do not want to open it up from the outside of your network due to security reasons, this is why this is done via the raspberry behind it.

The raspberry installation and network configuration here will be skipped, it is assumed that you have a working ssh client and server installed on it and your network works so you can access the internet from (and your external server) from it.

Via curl icanhazip.com you can easily get the external ip your router currently has, another possibility is to get it somehow directly from your router. The former is just way easier and will be used in the following.

BIND nowadays has the nsupdate facility (since v8? v9?), which lets you update the DNS remotely. Doing it via shellscripts and SSH will not work as the zonefile will be locked. Running scripts as root via SUID will not work, as this is prohibited by the OS due to security reasons.

A workaround would be a compiled C binary wrapper for the bash script, but just because it works does not mean you have to use it. Stick with nsupdate.

dns update in actual practice

create keypair

On the machine from where you want to update the DNS, you have to create a keypair. Use a valid email, with a . instead of an @.

dnssec-keygen -a HMAC-SHA512 -b 512 -n USER email.domain.tld

make the key known to BIND

Put the public part onto your dns server, and integrate it into BIND. Easiest and cleanest this is done like this, after scp'ing the pubkey up onto your server and into /etc/named/:

Insert into /etc/named.conf:

include "/etc/named.keys.conf";

Create /etc/named.keys.conf, and insert:

key email.domain.tld {
    algorithm HMAC-MD5;
    secret "insert-last-two-random-part-from-your-generated-public-key-file-into-here";
}

You might try using another algorithm, as there are several others available. But I am not sure, if the setup will work then.

configure management rights for the new key on the nameserver

The key could be either given full access, which I did not need, so it was just given partial access:

/etc/named.conf, add to dyn.mydomain.de zone:

update-policy {
    grant email.domain.tld subdomain dyn.mydomain.de A;
}

The part after grant is the keyname. Highlevel it is:

grant <key> <type> <zone> <RR> [<RR>];

Restart the nameserver, even though this might be unnecessary, to be safe.

configure the update script, the helper file plus the cronjob on the updating host

There are two files needed:

  1. the acutual script, which is run through the cron job
  2. the dns statements which nsudpate will execute, located in a second file
  3. Plus, the cronjob, so stuff is actually run in the end.

On the raspberry, for simplified reasons this is done as the root user:

mkdir /root/bin
touch /root/bin/update-dns.sh
chmod a+x /root/bin/update-dns.sh
touch /root/bin/dns-update.statements

Contents dns-update.statements:

server mydomain.de
zone dyn.mydomain.de
update delete dyn.mydomain.de A
update add dyn.mydomain.de 1800 A
show
send

Contents update-dns.sh:

#!/bin/bash
CURRENT="$(curl icanhazip.com)"
DNS="$(dig @ns.dyn.mydomain.de dyn.mydomain.de +short)"
## next two lines used for testing
#echo $CURRENT
#echo $DNS
if [ "$CURRENT" == "$DNS" ]; then exit 0; 
else 
    /bin/sed -i "s/\(update add dyn.mydomain.de 1800 A\).*/\1 $CURRENT/" /root/bin/dns-update.statements
    /usr/bin/nsupdate -k /etc/dns/Kemail.domain.tld.+157+26336.private -v /root/bin/dns-update.statements
fi

When it's shown like this here, it should be obvious where you have to apply changes for your setup:

  • after the -k flag, where your private key's name has to be entered
  • generally where mydomain is in use

Take special care, so the sed command will work, remember to change the "statements" file, too.

Actual testing did take place through adding echo's in every branch of the if statement, and running it every 5 seconds via watch:

watch -n5 -d /root/bin/update-dns.sh

That way I could identify errors easily. Once the update works, it will tell you then as the ip got changed. No need to restart or reload the BIND server.

If all is working as expected, remove the show from the statements file, we just needed it during testing.

Also add the cron in /etc/crontab:

*/15 * * * * root /root/bin/update-dns.sh

Afterwards service cron restart and you should have an updated DNS tomorrow and the day after tomorrow. And the following ones, of course. :)

The cron job does the checking every 15 minutes, if the ip has changed. Usually it would suffice if the check was done and run when the router resets.

But what about power outages? Router resets because somebody had to use the power outlet for the vacuum cleaner?
Just kidding, but it actually makes sense to update this periodically.

For questions I can be reached via twitter, see link on top of the site.

DNS: check server for misconfiguration
posted on 2015-04-03 21:10:48

To find out, if your provider's dns servers are misconfigured, such that an attacker can find out all subdomains to a given domain, try this:

dig AXFR <domain-name> @<ns-server-of-domain-name>

If it succeeds, the server is missing a whitelist of machines to where zone transfers are allowed, allowing everyone to request zone transfers.

DNS Howto
posted on 2014-11-22 23:46:28

DNS entries, which are called RR's (Resource Records), come in may different flavours. This post is intended to bring the absolute minimum knowledge to the table.

For a usual DNS entry, you need a pair of an A record, and a PTR record, if you want to be able to do reverse lookups. That means, having an ip, being able to resolve it back to a domain.

For convenience, there also exist CNAME records. These just redirect a domain to another domain (not an ip!).

SOA, MX, TXT and others will not be part of this post here.

A

my_domain_name.tld           ---   A   ---> 10.0.0.1

PTR

1.0.0.10.in-addr.arpa        ---  PTR  ---> my_domain_name.tld

CNAME

subdomain.my_domain_name.tld --- CNAME ---> my_domain_name.tld
my_second_domain.tld         --- CNAME ---> my_domain_name.tld

The use case here ist, that you only have to change a single entry (the A record), when the IP changes, not all other (Sub-)Domains, too, as long as these are created as CNAME's.

This brings along a little increase in latency time, as technically looking up a domain will lead to two DNS lookups being processed.

On the other mentioned records some short words:

SOA = Start of Authority, this RR authorizes this nameserver being authorative for the given domain

TXT = i.e. can be used for SPF (Sender Policy Framework), to determine allowed foreign mailservers which may send mails

MX = tells the location of the mailserver of this domain. Several RR's can exist.

On how RR's are structured, what the timings are for and how to configure a bind9 server, another post will eventually come.

TTL values
posted on 2014-05-08 09:50:18

A list of commonly used TTL values (i.e. in DNS) settings.

(  60         =     1 m  )
   1800       =    30 m
   3600       =     1 h
   10800      =     3 h
   14400      =     4 h
   21600      =     6 h
   43200      =    12 h
   86400      =     1 d
   259200     =     3 d
   604800     =     7 d
   31536000   =   365 d

Going below 0,5h is usually forbidden. Mostly 24h are used for RR's (resource records, like A / NS / MX), to reduce traffic for the DNS servers.

This blog covers .csv, .htaccess, .pfx, .vmx, /etc/crypttab, /etc/network/interfaces, /etc/sudoers, /proc, 10.04, 14.04, AS, ASA, ControlPanel, DS1054Z, GPT, HWR, Hyper-V, IPSEC, KVM, LSI, LVM, LXC, MBR, MTU, MegaCli, PHP, PKI, R, RAID, S.M.A.R.T., SNMP, SSD, SSL, TLS, TRIM, VEEAM, VMware, VServer, VirtualBox, Virtuozzo, XenServer, acpi, adaptec, algorithm, ansible, apache, apachebench, apple, arcconf, arch, architecture, areca, arping, asa, asdm, awk, backup, bandit, bar, bash, benchmarking, binding, bitrate, blackarmor, blowfish, bochs, bond, bonding, booknotes, bootable, bsd, btrfs, buffer, c-states, cache, caching, ccl, centos, certificate, certtool, cgdisk, cheatsheet, chrome, chroot, cisco, clamav, cli, clp, clush, cluster, coleslaw, colorscheme, common lisp, console, container, containers, controller, cron, cryptsetup, csync2, cu, cups, cygwin, d-states, database, date, db2, dcfldd, dcim, dd, debian, debug, debugger, debugging, decimal, desktop, df, dhclient, dhcp, diff, dig, display manager, dm-crypt, dmesg, dmidecode, dns, docker, dos, drivers, dtrace, dtrace4linux, du, dynamictracing, e2fsck, eBPF, ebook, efi, egrep, emacs, encoding, env, error, ess, esx, esxcli, esxi, ethtool, evil, expect, exportfs, factory reset, factory_reset, factoryreset, fail2ban, fbsd, fedora, file, filesystem, find, fio, firewall, firmware, fish, flashrom, forensics, free, freebsd, freedos, fritzbox, fsck, fstrim, ftp, ftps, g-states, gentoo, ghostscript, git, git-filter-branch, github, gitolite, gnutls, gradle, grep, grml, grub, grub2, guacamole, hardware, haskell, hdd, hdparm, hellowor, hex, hexdump, history, howto, htop, htpasswd, http, httpd, https, i3, icmp, ifenslave, iftop, iis, imagemagick, imap, imaps, init, innoDB, inodes, intel, ioncube, ios, iostat, ip, iperf, iphone, ipmi, ipmitool, iproute2, ipsec, iptables, ipv6, irc, irssi, iw, iwconfig, iwlist, iwlwifi, jailbreak, jails, java, javascript, javaws, js, juniper, junit, kali, kde, kemp, kernel, keyremap, kill, kpartx, krypton, lacp, lamp, languages, ldap, ldapsearch, less, leviathan, liero, lightning, links, linux, linuxin3months, lisp, list, livedisk, lmctfy, loadbalancing, locale, log, logrotate, looback, loopback, losetup, lsblk, lsi, lsof, lsusb, lsyncd, luks, lvextend, lvm, lvm2, lvreduce, lxc, lxde, macbook, macro, magento, mailclient, mailing, mailq, manpages, markdown, mbr, mdadm, megacli, micro sd, microsoft, minicom, mkfs, mktemp, mod_pagespeed, mod_proxy, modbus, modprobe, mount, mouse, movement, mpstat, multitasking, myISAM, mysql, mysql 5.7, mysql workbench, mysqlcheck, mysqldump, nagios, nas, nat, nc, netfilter, networking, nfs, nginx, nmap, nocaps, nodejs, numberingsystem, numbers, od, onyx, opcode-cache, openVZ, openlierox, openssl, openvpn, openvswitch, openwrt, oracle linux, org-mode, os, oscilloscope, overview, parallel, parameter expansion, parted, partitioning, passwd, patch, pdf, performance, pfsense, php, php7, phpmyadmin, pi, pidgin, pidstat, pins, pkill, plesk, plugin, posix, postfix, postfixadmin, postgres, postgresql, poudriere, powershell, preview, profiling, prompt, proxmox, ps, puppet, pv, pvecm, pvresize, python, qemu, qemu-img, qm, qmrestore, quicklisp, r, racktables, raid, raspberry pi, raspberrypi, raspbian, rbpi, rdp, redhat, redirect, registry, requirements, resize2fs, rewrite, rewrites, rhel, rigol, roccat, routing, rs0485, rs232, rsync, s-states, s_client, samba, sar, sata, sbcl, scite, scp, screen, scripting, seafile, seagate, security, sed, serial, serial port, setup, sftp, sg300, shell, shopware, shortcuts, showmount, signals, slattach, slip, slow-query-log, smbclient, snmpget, snmpwalk, software RAID, software raid, softwareraid, sophos, spacemacs, spam, specification, speedport, spi, sqlite, squid, ssd, ssh, ssh-add, sshd, ssl, stats, storage, strace, stronswan, su, submodules, subzone, sudo, sudoers, sup, swaks, swap, switch, switching, synaptics, synergy, sysfs, systemd, systemtap, tar, tcpdump, tcsh, tee, telnet, terminal, terminator, testdisk, testing, throughput, tmux, todo, tomcat, top, tput, trafficshaping, ttl, tuning, tunnel, tunneling, typo3, uboot, ubuntu, ubuntu 16.04, udev, uefi, ulimit, uname, unetbootin, unit testing, upstart, uptime, usb, usbstick, utf8, utm, utm 220, ux305, vcs, vgchange, vim, vimdiff, virtualbox, virtualization, visual studio code, vlan, vmstat, vmware, vnc, vncviewer, voltage, vpn, vsphere, vzdump, w, w701, wakeonlan, wargames, web, webdav, weechat, wget, whois, wicd, wifi, windowmanager, windows, wine, wireshark, wpa, wpa_passphrase, wpa_supplicant, x2x, xfce, xfreerdp, xmodem, xterm, xxd, yum, zones, zsh

View posts from 2017-02, 2017-01, 2016-12, 2016-11, 2016-10, 2016-09, 2016-08, 2016-07, 2016-06, 2016-05, 2016-04, 2016-03, 2016-02, 2016-01, 2015-12, 2015-11, 2015-10, 2015-09, 2015-08, 2015-07, 2015-06, 2015-05, 2015-04, 2015-03, 2015-02, 2015-01, 2014-12, 2014-11, 2014-10, 2014-09, 2014-08, 2014-07, 2014-06, 2014-05, 2014-04, 2014-03, 2014-01, 2013-12, 2013-11, 2013-10


Unless otherwise credited all material Creative Commons License by sjas