As I found out in my last post about NetBSD 7 RC 3, there have been some problems with it and I wanted to try it out in VirtualBox. Finally, I have done that yesterday and I saw that NetBSD 7 performs quite well in VirtualBox. However, at first it was also not possible to set another background picture. The reason for that was that "xfdesktop" - which manages the desktop in XFCE - wasn't installed (which I have expected it to do when issued "pkgin install xfce"). The package's name in NetBSD is " xfce4-desktop". I tried to let it install by pkgin, but that failed, which showed me some lines in /var/db/pkgin/pkg_install-err.log:
---Nov 06 20:40:55: installing xfce4-desktop-4.12.3...
pkg_add: no pkg found for 'tdb>=1.2.10', sorry.
pkg_add: Can't install dependency tdb>=1.2.10
I installed that package "tdb" and afterwards, xfce4-desktop could be installed. Since that moment it's possible to set another background picture in XFCE.
Other IMHO useful packages I installed:
firefox icedtea-web xpdf nmap iftop libreoffice-5* xfce4-screenshooter xfce4-weather* xfce4-cpugraph* xfce4-battery* xfce4-systemload-plugin gnome-screensaver gnome-audio gnome-backgrounds gnome-system-monitor gnome-system-tools xfce4-thunar sysupgrade sudo
For some experiments I also installed: lighttpd tuxpaint
Most of these packages worked, except gnome-system-monitor. gnome-about worked after I installed "py27-gtk". It's wise to start gnome-screensaver-settings once to setup the screen saver.
lighttpd didn't work after installing it. Unfortunately, pkgin doesn't copy any files necessary to actually run lighttpd (like apt-get does on Debian). This can be done with these commands:
cp -v /usr/pkg/share/examples/rc.d/lighttpd /etc/rc.d/
cp -v /usr/pkg/share/examples/lighttpd/lighttpd.conf /etc/lighttpd/
/etc/lighttpd/lighttpd.conf should be reviewed. Using
service lighttpd start
lighttpd can be started. Using
mkdir -p /srv/www/htdocs
it is possible to create the directory where files are being searched, unless this setting has not been changed in lighttpd.conf (see variable "server.document-root"). In my case, lighttpd now only serves files via IPv6, which can be seen if "netstat -f inet6 -a" is executed:
Active Internet6 connections (including servers)
Proto Recv-Q Send-Q Local Address Foreign Address (state)
tcp6 0 0 *.http *.* LISTEN
tcp6 0 0 *.x11 *.* LISTEN
tcp6 0 0 *.ssh *.* LISTEN
tcp6 0 0 *.sunrpc *.* LISTEN
udp6 0 0 fe80::1%lo0.ntp *.*
udp6 0 0 localhost.ntp *.*
udp6 0 0 2001:470:1f0b:2e.ntp *.*
udp6 0 0 fe80::a00:27ff:f.ntp *.*
udp6 0 0 *.ntp *.*
udp6 0 0 *.* *.*
udp6 0 0 *.1023 *.*
udp6 0 0 *.sunrpc *.*
If "inet" is used instead of "inet6", no "http" is listed.
Samstag, 7. November 2015
Freitag, 21. August 2015
First look at NetBSD 7 RC 3 and XFCE
The NetBSD team released RC 3 of NetBSD 7 this week and I was just too curious about its progress, so I downloaded both the i386 and x86_64 ISOs. I set it up in a virtual machine that I virtualised using Qemu 2.0.0 on my Xubuntu 14.04 system. First I had some trouble with the installer. I unaccidently selected a wrong option and then cancelled with Ctrl+C. Although I finished the installation normally, the system didn't boot correctly but dropped me on a shell with the hint, that /etc/rc.conf would contain RC_CONFIGURED=NO. I had no clue at that time how to solve that, especially how to mount the root filesystem read/write. In the meantime I found out that it isn't that hard: "mount -u -w /" would do the trick.
However, I just started the installation again (which is really fast and takes just a few minutes) but I had yet another problem: When trying to setup pkgin, that failed because it said it couldn't download something from "http://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/7.0_RC3/". In fact, that directory doesn't exist. I realised that there is path to "7.0" (without the "_RC3") and changed the path accordingly. The installer warned me that at least one package was build for RC 2 rather than RC 3 but I decided to accept this and the installation went fine.
After installing the "usual suspicous" packages (bash, nano), I installed XFCE and was very delighted that it made a huge jump from version 4.6 in NetBSD 6 to 4.12 in NetBSD 7. A first trial was a little bit disappointing: The performance was quite poor, the mouse pointer disappeared and appeared again continuously and there was a background with vertical black and white stripes in contrast to what was set up in the settings dialog.
To demonstrate this, I made a short, two minutes video.
If I have the change to do it, I will try installating NetBSD 7 RC 3 inside VirtualBox and see if it performs better there.
However, I just started the installation again (which is really fast and takes just a few minutes) but I had yet another problem: When trying to setup pkgin, that failed because it said it couldn't download something from "http://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/7.0_RC3/". In fact, that directory doesn't exist. I realised that there is path to "7.0" (without the "_RC3") and changed the path accordingly. The installer warned me that at least one package was build for RC 2 rather than RC 3 but I decided to accept this and the installation went fine.
After installing the "usual suspicous" packages (bash, nano), I installed XFCE and was very delighted that it made a huge jump from version 4.6 in NetBSD 6 to 4.12 in NetBSD 7. A first trial was a little bit disappointing: The performance was quite poor, the mouse pointer disappeared and appeared again continuously and there was a background with vertical black and white stripes in contrast to what was set up in the settings dialog.
Figure 1: XFCE 4.12 in NetBSD 7 RC 3 with wrong background
To demonstrate this, I made a short, two minutes video.
If I have the change to do it, I will try installating NetBSD 7 RC 3 inside VirtualBox and see if it performs better there.
Montag, 13. April 2015
"No space left on device" while executing apt-get/dpkg: it's just inodes...
Today I wanted to install some software using "apt-get install", when it suddenly reported that there was no space left on a device. df -h reported me, that my root file system was almost full, so I looked what I could do and finally moved some big files to another partition. Although my system had then plenty enough free disk space, "apt-get" kept reporting low disk space. So I asked DuckDuckGo and Google for help and got it: Apparently even a file system with enough free space can be full - if it ran out of inodes! df -i then showed me, that almost 100% of all inodes were used. So I was curious what caused those troubles. On [1] I found a quite useful command which I even "pimped" a little bit:
$ for i in /*; do echo $i has `find $i | wc -l` files; done
which outputs something like
/bin has 153 files
/boot has 262 files
and so on.
Or use
$ for i in /*; do echo `find $i | wc -l` files in $i; done
if you would like to have the numbers first:
153 files in /bin
262 files in /boot
Piping the output to "sort -n" does sorting, but you have to wait for the command to complete:
$ for i in /var/*; do echo `find $i | wc -l` files in $i; done | sort -n
1 files in /var/crash
1 files in /var/local
...
600 files in /var/log
11066 files in /var/lib
Using that command, I found out that "/usr" has many files, so I replaced "/*" by "/usr/*" and figured out that /usr/src was the really bad directory on the file system. I didn't notice yet that removing a Linux kernel doesn't remove the according headers. This must be done manually. To see all currently installed header packages, it's possible to use
$ dpkg --list | grep linux-headers
Those packages have really huge numbers of files! For Linux 3.2.0-80, there are two directories in /usr/src: "linux-headers-3.2.0-80" and "linux-headers-3.2.0-80-generic" which together have 22042 (!) files! And I had 28 of those on my system...
Conclusion: After "apt-get remove linux-headers-3.2.0-24 linux-headers-3.2.0-25-generic linux-headers-3.2.0-26-generic..." I had 167098 free inodes, which should be safe for the upcoming weeks. In future, I will monitor this value to avoid troubles.
[1] http://www.ivankuznetsov.com/2010/02/no-space-left-on-device-running-out-of-inodes.html
$ for i in /*; do echo $i has `find $i | wc -l` files; done
which outputs something like
/bin has 153 files
/boot has 262 files
and so on.
Or use
$ for i in /*; do echo `find $i | wc -l` files in $i; done
if you would like to have the numbers first:
153 files in /bin
262 files in /boot
Piping the output to "sort -n" does sorting, but you have to wait for the command to complete:
$ for i in /var/*; do echo `find $i | wc -l` files in $i; done | sort -n
1 files in /var/crash
1 files in /var/local
...
600 files in /var/log
11066 files in /var/lib
Using that command, I found out that "/usr" has many files, so I replaced "/*" by "/usr/*" and figured out that /usr/src was the really bad directory on the file system. I didn't notice yet that removing a Linux kernel doesn't remove the according headers. This must be done manually. To see all currently installed header packages, it's possible to use
$ dpkg --list | grep linux-headers
Those packages have really huge numbers of files! For Linux 3.2.0-80, there are two directories in /usr/src: "linux-headers-3.2.0-80" and "linux-headers-3.2.0-80-generic" which together have 22042 (!) files! And I had 28 of those on my system...
Conclusion: After "apt-get remove linux-headers-3.2.0-24 linux-headers-3.2.0-25-generic linux-headers-3.2.0-26-generic..." I had 167098 free inodes, which should be safe for the upcoming weeks. In future, I will monitor this value to avoid troubles.
[1] http://www.ivankuznetsov.com/2010/02/no-space-left-on-device-running-out-of-inodes.html
Freitag, 27. März 2015
Moving Active Directory integrated DNS zones from Windows 2000 Server to bind9
Since some weeks I am in the act of moving services from my virtual Windows 2000 server to my Ubuntu 12.04 machine. The first step was moving all files out of it so they are saved on my Ubuntu machine.
This post is about moving the Active Directory integrated DNS zones from Windows 2000 to bind9. First, a little bit about my current setup: 192.168.1.1, named speedy, offers DHCP and DNS services, while 192.168.1.2, named gspdc, offers Active Directory services and therefore also acts as a DNS server. Requests belonging the AD integrated domain (greatsoft.local) are forwarded from speedy to gspdc. This KB article from Microsoft shows an easy way to get all AD integrated DNS zones in files so that they could be processed by bind9. The easy trick is to simply convert those zones to "primary zone files": Afterwards, they are saved in the default DNS directory (that is normally %WINDIR%\System32\DNS). To get them to Ubuntu, I use SMB, so I first activated sharing the directory as "dns". On Ubuntu, I mounted the share:
root@speedy:/mnt # mount -t cifs //192.168.1.2/dns temp -o username=Administrator
Then I copied the files to /etc/bind9:
root@speedy:/mnt # cp -v temp/*dns /etc/bind
To make the database file names compliant with the standard of bind9, I renamed all of them and gave them a "db." prefix like all other database files have.
Until that moment, I used forwarding in bind9 to get DNS requests for *.virtual, *.greatsoft.local (AD integrated) and reverse DNS requests belonging 192.168.0.0/16 being resolved by Windows 2000.
root@speedy:/etc/bind # cat named.conf.gspdc
zone "greatsoft.local" {
type forward;
forwarders { 192.168.1.2; };
};
zone "virtual" {
type forward;
forwarders { 192.168.1.2; };
};
zone "168.192.in-addr.arpa" {
type forward;
forwarders { 192.168.1.2; };
};
That's not necessary any more: now the zone files are available in /etc/bind. In that directory, I edited named.conf and commented out the reference to named.conf.gspdc. The replace these zones, I created three files: named.conf.greatsoft.local, named.conf.virtual and named.conf.192.168.1.x.subnet which have contents like the following:
root@speedy:/etc/bind # cat named.conf.greatsoft.local
zone "greatsoft.local" {
type master;
file "/etc/bind/db.greatsoft.local.dns";
};
In contrast to the previous situation, I now have separate files for every /24 of 192.168.0.0/16, so reverse DNS queries for 192.168.1.0/24 are resolved by a different file than those for 192.168.2.0/24. I think that's easier to manage, because otherwise the zone database file could get too large.
Next task it to add those new named.conf.* files to the main configuration file, named.conf:
include "/etc/bind/named.conf.192.168.1.x.subnet";
include "/etc/bind/named.conf.greatsoft.local";
include "/etc/bind/named.conf.virtual";
Now it's time to restart bind9 by "service bind9 restart" and troubles finally begin. A simple "nslookup www.mkcs.at.virtual 192.168.1.1" just returns "** server can't find www.mkcs.at.virtual: SERVFAIL". But a "host -t TXT test.virtual" returns the text that I entered for it once (just for test purposes, as the name suggests), the same is true for my test entries for "test.test.virtual" (type A) and "eee1.test.virtual" (type AAAA). Using "grep named /var/log/syslog | tail -30" I found an interesting line:
/etc/bind/greatsoft.local.dns:33: gc._msdcs.greatsoft.local: bad owner name (check-names)
That is line 33 of file greatsoft.local.dns:
gc._msdcs 600 A 192.168.1.2
It's yet unclear to me why this causes an error. However, that entry was used by Active Directory, which I am about to deactivate, so I can relinquish entries like that. After uncommenting this line and the following lines that belong to that entry "gc._msdcs", I use
service bind9 reload
to tell bind9 it should reload its configuration and voilà, it works (tested from a client PC in my network):
michael@michimain1404:~$ host -t A www.mkcs.at.virtual
www.mkcs.at.virtual is an alias for w3mkcs.greatsoft.local.
w3mkcs.greatsoft.local has address 192.168.1.64
That's it! The final steps in deactivating that old (virtual) system will be shutting it down, (finally!) uninstalling VMware and then move it to a safe place in case I still need some data from it.
If anyone has suggestions for me how to improve that process, just let me know, I'd be curious!
This post is about moving the Active Directory integrated DNS zones from Windows 2000 to bind9. First, a little bit about my current setup: 192.168.1.1, named speedy, offers DHCP and DNS services, while 192.168.1.2, named gspdc, offers Active Directory services and therefore also acts as a DNS server. Requests belonging the AD integrated domain (greatsoft.local) are forwarded from speedy to gspdc. This KB article from Microsoft shows an easy way to get all AD integrated DNS zones in files so that they could be processed by bind9. The easy trick is to simply convert those zones to "primary zone files": Afterwards, they are saved in the default DNS directory (that is normally %WINDIR%\System32\DNS). To get them to Ubuntu, I use SMB, so I first activated sharing the directory as "dns". On Ubuntu, I mounted the share:
root@speedy:/mnt # mount -t cifs //192.168.1.2/dns temp -o username=Administrator
Then I copied the files to /etc/bind9:
root@speedy:/mnt # cp -v temp/*dns /etc/bind
To make the database file names compliant with the standard of bind9, I renamed all of them and gave them a "db." prefix like all other database files have.
Until that moment, I used forwarding in bind9 to get DNS requests for *.virtual, *.greatsoft.local (AD integrated) and reverse DNS requests belonging 192.168.0.0/16 being resolved by Windows 2000.
root@speedy:/etc/bind # cat named.conf.gspdc
zone "greatsoft.local" {
type forward;
forwarders { 192.168.1.2; };
};
zone "virtual" {
type forward;
forwarders { 192.168.1.2; };
};
zone "168.192.in-addr.arpa" {
type forward;
forwarders { 192.168.1.2; };
};
That's not necessary any more: now the zone files are available in /etc/bind. In that directory, I edited named.conf and commented out the reference to named.conf.gspdc. The replace these zones, I created three files: named.conf.greatsoft.local, named.conf.virtual and named.conf.192.168.1.x.subnet which have contents like the following:
root@speedy:/etc/bind # cat named.conf.greatsoft.local
zone "greatsoft.local" {
type master;
file "/etc/bind/db.greatsoft.local.dns";
};
In contrast to the previous situation, I now have separate files for every /24 of 192.168.0.0/16, so reverse DNS queries for 192.168.1.0/24 are resolved by a different file than those for 192.168.2.0/24. I think that's easier to manage, because otherwise the zone database file could get too large.
Next task it to add those new named.conf.* files to the main configuration file, named.conf:
include "/etc/bind/named.conf.192.168.1.x.subnet";
include "/etc/bind/named.conf.greatsoft.local";
include "/etc/bind/named.conf.virtual";
Now it's time to restart bind9 by "service bind9 restart" and troubles finally begin. A simple "nslookup www.mkcs.at.virtual 192.168.1.1" just returns "** server can't find www.mkcs.at.virtual: SERVFAIL". But a "host -t TXT test.virtual" returns the text that I entered for it once (just for test purposes, as the name suggests), the same is true for my test entries for "test.test.virtual" (type A) and "eee1.test.virtual" (type AAAA). Using "grep named /var/log/syslog | tail -30" I found an interesting line:
/etc/bind/greatsoft.local.dns:33: gc._msdcs.greatsoft.local: bad owner name (check-names)
That is line 33 of file greatsoft.local.dns:
gc._msdcs 600 A 192.168.1.2
It's yet unclear to me why this causes an error. However, that entry was used by Active Directory, which I am about to deactivate, so I can relinquish entries like that. After uncommenting this line and the following lines that belong to that entry "gc._msdcs", I use
service bind9 reload
to tell bind9 it should reload its configuration and voilà, it works (tested from a client PC in my network):
michael@michimain1404:~$ host -t A www.mkcs.at.virtual
www.mkcs.at.virtual is an alias for w3mkcs.greatsoft.local.
w3mkcs.greatsoft.local has address 192.168.1.64
That's it! The final steps in deactivating that old (virtual) system will be shutting it down, (finally!) uninstalling VMware and then move it to a safe place in case I still need some data from it.
If anyone has suggestions for me how to improve that process, just let me know, I'd be curious!
Abonnieren
Posts (Atom)