How to See Samba Shares on a Windows 10 Network

wsdd is a service by christgau on GitHub, which implements a Web Service Discovery host daemon for Ubuntu. This enables Samba hosts to be found by Web Service Discovery Clients like Windows 10.

If you are experiencing any issues with this service, please let us know in the comments or submit an issue on GitHub.

Change to /tmp directory.

cd /tmp

Download and unzip the archive.



Rename to wsdd.

sudo mv wsdd-master/src/ wsdd-master/src/wsdd

Copy to /usr/bin.

sudo cp wsdd-master/src/wsdd /usr/bin

Copy wsdd to /etc/systemd/system.

sudo cp wsdd-master/etc/systemd/wsdd.service /etc/systemd/system

Open wsdd.service in nano and comment out User=nobody and Group=nobody with a ; semicolon.

sudo nano /etc/systemd/system/wsdd.service
Description=Web Services Dynamic Discovery host daemon
; Start after the network has been configured
; It makes sense to have Samba running when wsdd starts, but is not required

ExecStart=/usr/bin/wsdd --shortlog
; Replace those with an unprivledged user/group that matches your environment,
; like nobody/nogroup or daemon:daemon or a dedicated user for wsdd
; User=nobody
; Group=nobody
; The following lines can be used for a chroot execution of wsdd.
; Also append '--chroot /run/wsdd/chroot' to ExecStart to enable chrooting
;ExecStartPre=/usr/bin/install -d -o nobody -g nobody -m 0700 /run/wsdd/chroot
;ExecStopPost=rmdir /run/wsdd/chroot


Save and exit (press CTRL + X, press Y and then press ENTER)

Start and enable wsdd.

sudo systemctl start wsdd
sudo systemctl enable wsdd


Created symlink /etc/systemd/system/ → /etc/systemd/system/wsdd.service.

Now check that the service is running.

sudo service wsdd status


wsdd.service - Web Services Dynamic Discovery host daemon
Loaded: loaded (/etc/systemd/system/wsdd.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2020-06-10 10:51:39 CEST; 8s ago
Main PID: 40670 (python3)
Tasks: 1 (limit: 6662)
Memory: 10.8M
CGroup: /system.slice/wsdd.service
└─40670 python3 /usr/bin/wsdd --shortlog

jun 10 10:51:39 ubuntu systemd[1]: Started Web Services Dynamic Discovery host daemon.
jun 10 10:51:40 ubuntu wsdd[40670]: WARNING: no interface given, using all interfaces

You should now be able to browse your Ubuntu machines and Samba shares in the Windows 10 file explorer. You may need to restart the Windows 10 machines to force discovery.

You may also want to reboot the Ubuntu server just to make sure the wsdd service starts up automatically without issue.
How to Uninstall wsdd

If you want to completely uninstall wsdd, stop and disable the service.

sudo systemctl stop wsdd
sudo systemctl disable wsdd

Remove wsdd from /usr/bin.

sudo rm /usr/bin/wsdd

Remove service file.

sudo rm /etc/systemd/system/wsdd.service

Figuring out what hardware version of the Raspberry Pi you are using

So you are spending the night messing around with your Raspberry Pi’s and forgotten what version you are using, instead of having to take the cover of the RPi or walk over to the closet, to see what version it is, you can do this remote from the command line.

From the command line issue the following command:

cat /proc/cpuinfo

output should be something like this:

processor       : 3
model name      : ARMv7 Processor rev 4 (v7l)
BogoMIPS        : 38.40
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xd03
CPU revision    : 4

Hardware        : BCM2835
Revision        : a02082
Serial          : 0000000000000000
pi@bifrost:~ $

look for the part in the bottom saying Revision (in my case it’s a02082)

now use the following list to fire out what hardware it is.:

900021A+1.1512MBSony UK
900032B+1.2512MBSony UK
900092Zero1.2512MBSony UK
900093Zero1.3512MBSony UK
9000c1Zero W1.1512MBSony UK
9020e03A+1.0512MBSony UK
900061CM1.1512MBSony UK
a010402B1.01GBSony UK
a010412B1.11GBSony UK
a020823B1.21GBSony UK
a020a0CM31.01GBSony UK
a020d33B+1.31GBSony UK
a020422B (with BCM2837)1.21GBSony UK
a220422B (with BCM2837)1.21GBEmbest
a320823B1.21GBSony Japan
a02100CM3+1.01GBSony UK
a031114B1.11GBSony UK
b031114B1.12GBSony UK
c031114B1.14GBSony UK
c031124B1.24GBSony UK
Hardware revison overview

See More here:

Servicing an MindrayPM-8000 Patient Monitor

So this patient monitor was complaining about the clock was off every time it was started, the most obvious problem would be the RTC backup battery for the unit.

I started out by removing the panels that i could find but properly by design they choose not to make this user exchangeable.

The battery neede for the job is an CR1220 3V lithium cell (i always choose batteries from Panasonic for such an task)

First of all Sorry for the crappy picture quality

Unit from the front

From the back (yes i removed the serial number on the unit)
You will need to to remove the screws on the back from peel of the front of the unit.

Gently remove the front panel, be careful with the cables, they can be disconnected with ease.

View of the panel.

High voltage converter for the CCFL lamp inside the panel

Slide the panel to the side and in an upper left corner the battery is located, pop out the battery and exchange it with the new one (be carefully not to touch the battery use some paper when mounting it.

Reverse the process to assemble the unit.

After the battery have been changed you need to setup the clock again, and this should be it, the new battery should work for the next 7 years, depending on usage.

Reset Windows 7 rearm count



An install of Windows 7 without an activation key allows for 30 days of usage. This can however be extended up to 120 days by using the following slmgr (Software Licensing Management Tool) command to rearm or reset the 30 day trial.

slmgr /rearm

(Remember to run this command, you must right click on cmd and select “Run as administrator” for this to work) However this can only be done up to 4 times. You can view the number of rearm counts by using the command which displays the current license information:

slmgr /dlv

Notice the second to last line shows that I only have 1 more remaining rearm, after which the software will expire. However there is a small trick that allows you to reset the rearm count back to 4. To do this you need delete the registry key which contains the Last Rearm Time, however this key can not be deleted or modified during a normal user session. To delete the key you will need to run the following commands in the windows recovery console.

reg load HKLM\MY_SYSTEM "%~dp0Windows\System32\config\system"
reg delete HKLM\MY_SYSTEM\WPA /f
reg unload HKLM\MY_SYSTEM

To do this save the above commands to a .bat file ‘reset.bat’ to the C:\ root folder. Restart your computer, pressing F8 to get to the Advanced Boot Options. Select the option to Repair Your Computer. Select your keyboard input method. Login with your login details. In the System Recovery Options menu, select Command Prompt. Now type in C:\reset.bat. (If it says “‘C:\reset.bat’ is not a recognised as in internal or external command” message, then it may be because the  C Drive is bring used as a recovery partition. Try again using D:\reset.bat) If successfully you should get the message “The operation completed successfully”. Next reboot your machines.

After rebooting you may get a message stating that this product is not genuine. This can be ignored. Running slmgr /dlv again will confirm that the rearm count has been increased again, thereby giving you another 120 days worth of windows use.

New house and new server room.

Well I bought an old house from 1965, back in November 2016, and still working on getting all rooms renovated, but one of the more exciting things about the new house, was the possibility to get a dedicated room for my servers, and networking hardware.

Unfortunately i haven’t got any pictures from the starting point, but the room size is:         120 x 180cm (47,2 x 70.8 inch).

Just big enough to accommodate an 42U 19″ rack, I bought an used HP G10000 G2 Rack of got the item for an good price.

Spec for the rack can be found her:

I have been used to work with the HP G10000 Series rack at work, for numerous customer projects, and really like the mounting options inside the rack, with the D rings and etc.

3/12-2016 Started working on the walls. and adding the new dedicated power for the room, the power will consist of 3 x 13A phases each with it’s own RCD on each phase, this will be more power than i need, but it was the most easy install to do.

As the picture shows, there is an tubes sticking up from the flooring, this is my district heating that is being installed, unfortunately this was the only option available for getting it in the house without tearing the whole ting down.

4/2-2017: new ceiling made from plaster wall.

7/2-2017: the heating have been connected and working, it’s time for the flooring 🙂 i decided on tiles, as it should be easy to clean and wipe for any dust

11/2-2017: Time to get the rack in 🙂

30/3-2017: Time to get some equipment in the rack (I know the cabling is an mess but i needed to get things up and running again.

2/5-2017: Had my new 100/100Mbit FTTH installed today, my secondary line is an VDSL2 (40/12Mbit)

27/5-2017: my cousin installed the new door 🙂 starting to look more finished then ever, still need to do the wiring inside the room and rack.

30/7-2017: Decided to install cable trays in the ceiling like the normal trays used in the data centers that i do work in.

Just missing one power outlet, and mounting of the telephone jack, on the cable tray.

Power distrubution panel (each phase has it’s own RCD and automatic fuse):

31/12-2017: replaced my Ubiquiti Edgerouters and my Zyxel switch, with an USG-PRO-4 Router and 2 switches (US-16-150W and a US‑24) this way i can power my AP’s and further security cameras, the US-24 will mostly do networking for alle the rooms, where i don’t need  POE.

Udskift din TDC Homebox med et modem.

This Article is in danish as it primary readers should be danish :).


22/05-2018 updated: Jeg har smidt min seneste version fil op, efter at jeg måtte sætte et nyt modem op grundet at den Zyxel jeg egenlig have skiftet over til døde efter overspænding på porten og tog en del andet udstyr med i faldet, så snart jeg har en ny Zyxel så smider jeg config op til denne :).

Jeg har i flere år brugt mit eget modem på min TDC ADSL2+ forbindelse (20/2Mbit), i forbindelse med omlægning til en 40/10Mbit forbindelse, blev jeg konverteret til en VDSL2 forbindelse, mit god gamle netgear DM111 ADSL2+ modem, skulle derfor udskiftes til noget som kan forstå VDSL2.

Jeg havde ved et held fået et TDC VDSL2 modem (Askey RTV1800-D79), dette modem understøtter iht. til TDC’s lister både Vectoring, SRA, samt G.INP, hvilket burde sikre driften i langtid.

OBS: jeg har godt nok telefon på mit abb. men jeg bruger det ikke, så disse noter drejer kun om at få internet igennem.

i min naivitet troede jeg at der ikke var forskel på en modem løsning og en router løsning (Homebox), dette viste sig dog at der var stor forskel.

følgende er de settings jeg er bekendt med:

VLAN ID = 101
QOS = 1

VLAN ID = 50
QOS = 0

Modem settings er fisket ud ved at tilgå på modemet, Homebox settings er fundet å TDC’s forum.

for at tilgå modem, skal det lige have et spark over benet ved at reset det, hold reset knappen inde indtil at alle lamper blinker, gør dette nogle gange (det kan godt drille), forsøg derefter at tilgå den på, når det lykkes skuælle den gerne komme op og spørge om login, her bruger du admin som bruger og password.

man kan via modemet hive settings ud, men umiddelbart ikke ændre noget på denne, dette kan man dog workaround ved at redigere den fil man får ud af settings, jeg ligger hermed min originale fil op samt den redigeret fil som fik min forbindelse til at virke.


Original settings fra modem (TDC Setup):

Orginale setting fra modem (Hiper Setup):

De settings jeg kører med idag:

UPDATE nye settings:

NB: Filerne er pakket som ZIP filer, da det gav lidt problemer med encodningen og er derved lige til at smide på boksen.

God fornøjelse med at få det til at spille 🙂

den primære ændring er:


<WANIPConnection instance=”1″>
<ExternalIPAddress notification=”2″></ExternalIPAddress>

Modificeret version:

<WANIPConnection instance=”1″>
<ExternalIPAddress notification=”2″></ExternalIPAddress>

Jeg vil sandsynligvis skrive mere her ved lejlighed, når jeg får mere tid til at kigge på settings.

How To Configure BIND as a Private DNS Server

Found this great tutorial for setting up Bind as a private DNS server.

copied the article for later use 🙂

How To Configure BIND as a Private Network DNS Server on Ubuntu 14.04


An important part of managing server configuration and infrastructure includes maintaining an easy way to look up network interfaces and IP addresses by name, by setting up a proper Domain Name System (DNS). Using fully qualified domain names (FQDNs), instead of IP addresses, to specify network addresses eases the configuration of services and applications, and increases the maintainability of configuration files. Setting up your own DNS for your private network is a great way to improve the management of your servers.

In this tutorial, we will go over how to set up an internal DNS server, using the BIND name server software (BIND9) on Ubuntu 14.04, that can be used by your Virtual Private Servers (VPS) to resolve private host names and private IP addresses. This provides a central way to manage your internal hostnames and private IP addresses, which is indispensable when your environment expands to more than a few hosts.

The CentOS version of this tutorial can be found here.


To complete this tutorial, you will need the following:

  • Some servers that are running in the same datacenter and have private networking enabled
  • A new VPS to serve as the Primary DNS server, ns1
  • Optional: A new VPS to serve as a Secondary DNS server, ns2
  • Root access to all of the above (steps 1-4 here)

If you are unfamiliar with DNS concepts, it is recommended that you read at least the first three parts of our Introduction to Managing DNS.

Example Hosts

For example purposes, we will assume the following:

  • We have two existing VPS called “host1” and “host2”
  • Both VPS exist in the nyc3 datacenter
  • Both VPS have private networking enabled (and are on the subnet)
  • Both VPS are somehow related to our web application that runs on “”

With these assumptions, we decide that it makes sense to use a naming scheme that uses “” to refer to our private subnet or zone. Therefore, host1‘s private Fully-Qualified Domain Name (FQDN) will be “”. Refer to the following table the relevant details:

Host Role Private FQDN Private IP Address
host1 Generic Host 1
host2 Generic Host 2

Note: Your existing setup will be different, but the example names and IP addresses will be used to demonstrate how to configure a DNS server to provide a functioning internal DNS. You should be able to easily adapt this setup to your own environment by replacing the host names and private IP addresses with your own. It is not necessary to use the region name of the datacenter in your naming scheme, but we use it here to denote that these hosts belong to a particular datacenter’s private network. If you utilize multiple datacenters, you can set up an internal DNS within each respective datacenter.

Our Goal

By the end of this tutorial, we will have a primary DNS server, ns1, and optionally a secondary DNS server, ns2, which will serve as a backup.

Here is a table with example names and IP addresses:

Host Role Private FQDN Private IP Address
ns1 Primary DNS Server
ns2 Secondary DNS Server

Let’s get started by installing our Primary DNS server, ns1.

Install BIND on DNS Servers

Note: Text that is highlighted in red is important! It will often be used to denote something that needs to be replaced with your own settings or that it should be modified or added to a configuration file. For example, if you see something like, replace it with the FQDN of your own server. Likewise, if you see host1_private_IP, replace it with the private IP address of your own server.

On both DNS servers, ns1 and ns2, update apt:

  • sudo apt-get update

Now install BIND:

  • sudo apt-get install bind9 bind9utils bind9-doc

IPv4 Mode

Before continuing, let’s set BIND to IPv4 mode. On both servers, edit the bind9 service parameters file:

  • sudo vi /etc/default/bind9

Add “-4” to the OPTIONS variable. It should look like the following:

OPTIONS="-4 -u bind"

Save and exit.

Now that BIND is installed, let’s configure the primary DNS server.

Configure Primary DNS Server

BIND’s configuration consists of multiple files, which are included from the main configuration file, named.conf. These filenames begin with “named” because that is the name of the process that BIND runs. We will start with configuring the options file.

Configure Options File

On ns1, open the named.conf.options file for editing:

  • sudo vi /etc/bind/named.conf.options

Above the existing options block, create a new ACL block called “trusted”. This is where we will define list of clients that we will allow recursive DNS queries from (i.e. your servers that are in the same datacenter as ns1). Using our example private IP addresses, we will add ns1, ns2, host1, and host2 to our list of trusted clients:

/etc/bind/named.conf.options — 1 of 3
acl "trusted" {;    # ns1 - can be set to localhost;    # ns2;  # host1;  # host2

Now that we have our list of trusted DNS clients, we will want to edit the options block. Currently, the start of the block looks like the following:

/etc/bind/named.conf.options — 2 of 3
options {
        directory "/var/cache/bind";

Below the directory directive, add the highlighted configuration lines (and substitute in the proper ns1 IP address) so it looks something like this:

/etc/bind/named.conf.options — 3 of 3
options {
        directory "/var/cache/bind";

        recursion yes;                 # enables resursive queries
        allow-recursion { trusted; };  # allows recursive queries from "trusted" clients
        listen-on {; };   # ns1 private IP address - listen on private network only
        allow-transfer { none; };      # disable zone transfers by default

        forwarders {

Now save and exit named.conf.options. The above configuration specifies that only your own servers (the “trusted” ones) will be able to query your DNS server.

Next, we will configure the local file, to specify our DNS zones.

Configure Local File

On ns1, open the named.conf.local file for editing:

  • sudo vi /etc/bind/named.conf.local

Aside from a few comments, the file should be empty. Here, we will specify our forward and reverse zones.

Add the forward zone with the following lines (substitute the zone name with your own):

/etc/bind/named.conf.local — 1 of 2
zone "" {
    type master;
    file "/etc/bind/zones/"; # zone file path
    allow-transfer {; };         # ns2 private IP address - secondary

Assuming that our private subnet is, add the reverse zone by with the following lines (note that our reverse zone name starts with “128.10” which is the octet reversal of “10.128”):

/etc/bind/named.conf.local — 2 of 2
zone "" {
    type master;
    file "/etc/bind/zones/db.10.128";  # subnet
    allow-transfer {; };  # ns2 private IP address - secondary

If your servers span multiple private subnets but are in the same datacenter, be sure to specify an additional zone and zone file for each distinct subnet. When you are finished adding all of your desired zones, save and exit the named.conf.local file.

Now that our zones are specified in BIND, we need to create the corresponding forward and reverse zone files.

Create Forward Zone File

The forward zone file is where we define DNS records for forward DNS lookups. That is, when the DNS receives a name query, “” for example, it will look in the forward zone file to resolve host1‘s corresponding private IP address.

Let’s create the directory where our zone files will reside. According to our named.conf.local configuration, that location should be /etc/bind/zones:

  • sudo mkdir /etc/bind/zones

We will base our forward zone file on the sample db.local zone file. Copy it to the proper location with the following commands:

  • cd /etc/bind/zones
  • sudo cp ../db.local ./

Now let’s edit our forward zone file:

  • sudo vi /etc/bind/zones/

Initially, it will look something like the following:

/etc/bind/zones/ — original
$TTL    604800
@       IN      SOA     localhost. root.localhost. (
                              2         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
@       IN      NS      localhost.      ; delete this line
@       IN      A       ; delete this line
@       IN      AAAA    ::1             ; delete this line

First, you will want to edit the SOA record. Replace the first “localhost” with ns1‘s FQDN, then replace “root.localhost” with “”. Also, every time you edit a zone file, you should increment the serial value before you restart the named process–we will increment it to “3”. It should look something like this:

/etc/bind/zones/ — updated 1 of 3
@       IN      SOA (
                              3         ; Serial

Now delete the three records at the end of the file (after the SOA record). If you’re not sure which lines to delete, they are marked with a “delete this line” comment above.

At the end of the file, add your nameserver records with the following lines (replace the names with your own). Note that the second column specifies that these are “NS” records:

/etc/bind/zones/ — updated 2 of 3
; name servers - NS records
    IN      NS
    IN      NS

Then add the A records for your hosts that belong in this zone. This includes any server whose name we want to end with “” (substitute the names and private IP addresses). Using our example names and private IP addresses, we will add A records for ns1, ns2, host1, and host2 like so:

/etc/bind/zones/ — updated 3 of 3
; name servers - A records          IN      A          IN      A

; - A records        IN      A        IN      A

Save and exit the file.

Our final example forward zone file looks like the following:

/etc/bind/zones/ — updated
$TTL    604800
@       IN      SOA (
                  3       ; Serial
             604800     ; Refresh
              86400     ; Retry
            2419200     ; Expire
             604800 )   ; Negative Cache TTL
; name servers - NS records
     IN      NS
     IN      NS

; name servers - A records          IN      A          IN      A

; - A records        IN      A        IN      A

Now let’s move onto the reverse zone file(s).

Create Reverse Zone File(s)

Reverse zone file are where we define DNS PTR records for reverse DNS lookups. That is, when the DNS receives a query by IP address, “” for example, it will look in the reverse zone file(s) to resolve the corresponding FQDN, “” in this case.

On ns1, for each reverse zone specified in the named.conf.local file, create a reverse zone file. We will base our reverse zone file(s) on the sample db.127 zone file. Copy it to the proper location with the following commands (substituting the destination filename so it matches your reverse zone definition):

  • cd /etc/bind/zones
  • sudo cp ../db.127 ./db.10.128

Edit the reverse zone file that corresponds to the reverse zone(s) defined in named.conf.local:

  • sudo vi /etc/bind/zones/db.10.128

Initially, it will look something like the following:

/etc/bind/zones/db.10.128 — original
$TTL    604800
@       IN      SOA     localhost. root.localhost. (
                              1         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
@       IN      NS      localhost.      ; delete this line
1.0.0   IN      PTR     localhost.      ; delete this line

In the same manner as the forward zone file, you will want to edit the SOA record and increment the serial value. It should look something like this:

/etc/bind/zones/db.10.128 — updated 1 of 3
@       IN      SOA (
                              3         ; Serial

Now delete the two records at the end of the file (after the SOA record). If you’re not sure which lines to delete, they are marked with a “delete this line” comment above.

At the end of the file, add your nameserver records with the following lines (replace the names with your own). Note that the second column specifies that these are “NS” records:

/etc/bind/zones/db.10.128 — updated 2 of 3
; name servers - NS records
      IN      NS
      IN      NS

Then add PTR records for all of your servers whose IP addresses are on the subnet of the zone file that you are editing. In our example, this includes all of our hosts because they are all on the subnet. Note that the first column consists of the last two octets of your servers’ private IP addresses in reversed order. Be sure to substitute names and private IP addresses to match your servers:

/etc/bind/zones/db.10.128 — updated 3 of 3
; PTR Records
11.10   IN      PTR    ;
12.20   IN      PTR    ;
101.100 IN      PTR  ;
102.200 IN      PTR  ;

Save and exit the reverse zone file (repeat this section if you need to add more reverse zone files).

Our final example reverse zone file looks like the following:

/etc/bind/zones/db.10.128 — updated
$TTL    604800
@       IN      SOA (
                              3         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
; name servers
      IN      NS
      IN      NS

; PTR Records
11.10   IN      PTR    ;
12.20   IN      PTR    ;
101.100 IN      PTR  ;
102.200 IN      PTR  ;

Check BIND Configuration Syntax

Run the following command to check the syntax of the named.conf* files:

  • sudo named-checkconf

If your named configuration files have no syntax errors, you will return to your shell prompt and see no error messages. If there are problems with your configuration files, review the error message and the Configure Primary DNS Server section, then try named-checkconf again.

The named-checkzone command can be used to check the correctness of your zone files. Its first argument specifies a zone name, and the second argument specifies the corresponding zone file, which are both defined in named.conf.local.

For example, to check the “” forward zone configuration, run the following command (change the names to match your forward zone and file):

  • sudo named-checkzone

And to check the “” reverse zone configuration, run the following command (change the numbers to match your reverse zone and file):

  • sudo named-checkzone /etc/bind/zones/db.10.128

When all of your configuration and zone files have no errors in them, you should be ready to restart the BIND service.

Restart BIND

Restart BIND:

  • sudo service bind9 restart

Your primary DNS server is now setup and ready to respond to DNS queries. Let’s move on to creating the secondary DNS server.

Configure Secondary DNS Server

In most environments, it is a good idea to set up a secondary DNS server that will respond to requests if the primary becomes unavailable. Luckily, the secondary DNS server is much easier to configure.

On ns2, edit the named.conf.options file:

  • sudo vi /etc/bind/named.conf.options

At the top of the file, add the ACL with the private IP addresses of all of your trusted servers:

/etc/bind/named.conf.options — updated 1 of 2 (secondary)
acl "trusted" {;   # ns1;   # ns2 - can be set to localhost;  # host1;  # host2

Below the directory directive, add the following lines:

/etc/bind/named.conf.options — updated 2 of 2 (secondary)
        recursion yes;
        allow-recursion { trusted; };
        listen-on {; };      # ns2 private IP address
        allow-transfer { none; };          # disable zone transfers by default

        forwarders {

Save and exit named.conf.options. This file should look exactly like ns1‘s named.conf.options file except it should be configured to listen on ns2‘s private IP address.

Now edit the named.conf.local file:

  • sudo vi /etc/bind/named.conf.local

Define slave zones that correspond to the master zones on the primary DNS server. Note that the type is “slave”, the file does not contain a path, and there is a masters directive which should be set to the primary DNS server’s private IP. If you defined multiple reverse zones in the primary DNS server, make sure to add them all here:

/etc/bind/named.conf.local — updated (secondary)
zone "" {
    type slave;
    file "slaves/";
    masters {; };  # ns1 private IP

zone "" {
    type slave;
    file "slaves/db.10.128";
    masters {; };  # ns1 private IP

Now save and exit named.conf.local.

Run the following command to check the validity of your configuration files:

  • sudo named-checkconf

Once that checks out, restart bind

  • sudo service bind9 restart

Now you have primary and secondary DNS servers for private network name and IP address resolution. Now you must configure your servers to use your private DNS servers.

Configure DNS Clients

Before all of your servers in the “trusted” ACL can query your DNS servers, you must configure each of them to use ns1 and ns2 as nameservers. This process varies depending on OS, but for most Linux distributions it involves adding your name servers to the /etc/resolv.conf file.

Ubuntu Clients

On Ubuntu and Debian Linux VPS, you can edit the head file, which is prepended to resolv.conf on boot:

  • sudo vi /etc/resolvconf/resolv.conf.d/head

Add the following lines to the file (substitute your private domain, and ns1 and ns2 private IP addresses):

search  # your private domain
nameserver  # ns1 private IP address
nameserver  # ns2 private IP address

Now run resolvconf to generate a new resolv.conf file:

  • sudo resolvconf -u

Your client is now configured to use your DNS servers.

CentOS Clients

On CentOS, RedHat, and Fedora Linux VPS, simply edit the resolv.conf file:

  • sudo vi /etc/resolv.conf

Then add the following lines to the TOP of the file (substitute your private domain, and ns1 and ns2 private IP addresses):

search  # your private domain
nameserver  # ns1 private IP address
nameserver  # ns2 private IP address

Now save and exit. Your client is now configured to use your DNS servers.

Test Clients

Use nslookup to test if your clients can query your name servers. You should be able to do this on all of the clients that you have configured and are in the “trusted” ACL.

Forward Lookup

For example, we can perform a forward lookup to retrieve the IP address of by running the following command:

  • nslookup host1

Querying “host1” expands to “ because of the search option is set to your private subdomain, and DNS queries will attempt to look on that subdomain before looking for the host elsewhere. The output of the command above would look like the following:



Reverse Lookup

To test the reverse lookup, query the DNS server with host1‘s private IP address:

  • nslookup

You should see output that looks like the following:

Address:   name =

If all of the names and IP addresses resolve to the correct values, that means that your zone files are configured properly. If you receive unexpected values, be sure to review the zone files on your primary DNS server (e.g. and db.10.128).

Congratulations! Your internal DNS servers are now set up properly! Now we will cover maintaining your zone records.

Maintaining DNS Records

Now that you have a working internal DNS, you need to maintain your DNS records so they accurately reflect your server environment.

Adding Host to DNS

Whenever you add a host to your environment (in the same datacenter), you will want to add it to DNS. Here is a list of steps that you need to take:

Primary Nameserver

  • Forward zone file: Add an “A” record for the new host, increment the value of “Serial”
  • Reverse zone file: Add a “PTR” record for the new host, increment the value of “Serial”
  • Add your new host’s private IP address to the “trusted” ACL (named.conf.options)

Then reload BIND:

  • sudo service bind9 reload

Secondary Nameserver

  • Add your new host’s private IP address to the “trusted” ACL (named.conf.options)

Then reload BIND:

  • sudo service bind9 reload

Configure New Host to Use Your DNS

  • Configure resolv.conf to use your DNS servers
  • Test using nslookup

Removing Host from DNS

If you remove a host from your environment or want to just take it out of DNS, just remove all the things that were added when you added the server to DNS (i.e. the reverse of the steps above).


Now you may refer to your servers’ private network interfaces by name, rather than by IP address. This makes configuration of services and applications easier because you no longer have to remember the private IP addresses, and the files will be easier to read and understand. Also, now you can change your configurations to point to a new servers in a single place, your primary DNS server, instead of having to edit a variety of distributed configuration files, which eases maintenance.

Once you have your internal DNS set up, and your configuration files are using private FQDNs to specify network connections, it is critical that your DNS servers are properly maintained. If they both become unavailable, your services and applications that rely on them will cease to function properly. This is why it is recommended to set up your DNS with at least one secondary server, and to maintain working backups of all of them.

list package after size in Debian/Ubuntu

I had a Ubuntu system where the root drive almost was full i suspected it was some packages that apt-get autoremove couldn’t remove, that was using the drive.

This small script will list the installed packages on your system ending with the biggest.

dpkg-query -W --showformat='${Installed-Size;10}\t${Package}\n' | sort -k1,1n

On my system this was a huge amount of old kernel images, and kernel sources that was installed.

to remove the packages i used:

apt-get remove --purge

to see the total amount of storage used and exclude the /mnt (all my discs are mounted here) use:

du -shc --exclude /mnt /*

vSphere 5.5 how to add domain users to SSO

Snipped this from:

So you’ve installed your ESX servers and installed vCenter along with its SSO, Inventory Services and Web Client, you’ve even installed the Windows vSphere UI just because that’s what you’re used to and now when you’re connecting to your new environment your getting a “You do not have permission to login to this server”



So with this new version of vSphere you need to enable access for your domain users/groups so that they have access to vCenter.

To get you up and running fast follow these simple steps. for best practices configuring SSO please reference the VMware documentation.

1. Login to the Web client “https://client-hostname:9443/vsphere-client” with administrator@vsphere.local using the password of what ever you configured SSO password as. *Note you can only configure SSO using the Web Client*

2. Navigate to vCenter Servers > Manage > Permissions, click on the + to add a user

3. Now add your Domain user or group that you would like to have access to vCenter along with the permissions required and click on OK.

4. Try and login with the user you just configured and you should now have access to the Web client or the Windows vSphere UI.