Configure Cisco GRE tunnel June 25th, 2009
| Configure Cisco GRE tunnel |
| Written by Reza Behroozi | |
| Saturday, 04 August 2007 | |
RouterB Config on RouterA : ip route 192.168.2.0 255.255.255.0 Tunnel0 Config on RouterB : ip route 192.168.1.0 255.255.255.0 Tunnel0 Thanks to Author, orignal link http://www.en.persianadmins.com/article/cisco/Configure_Cisco_GRE_tunnel_2007080417.html |
Microsoft SQL Server: How to Find the Foreign Keys in a Database June 21st, 2009
| A foreign key is a column or columns that are used to enforce a link between data in two tables. While SQL Server gives you no quick and easy way to view all foreign keys in a database, this quick query will give you that information. It comes in handy when trying to troubleshoot Foreign Key Constraint errors.
1. Open a New Query on the desired database. 2. Copy, paste, and execute the following: FROM FROM ON e.TABLE_NAME = d.TABLE_NAME ORDER BY a.CONSTRAINT_NAME You can now easily see all foreign keys in that database. courtesy http://www.tech-recipes.com/rx/3194/microsoft-sql-server-how-to-find-the-foreign-keys-in-a-database/ |
Debian Quick Start (incl. general GNU/Linux info) June 21st, 2009
by Lee on Sun May 10, 2009 4:16 am
Why Debian?
Most new Linux users go for Ubuntu, which is more than nice enough when compared to Windows, but still somewhat bloated, and you don’t really learn much. In my opinion, it also looks pretty bad. Ubuntu and many other of the more user-friendly distros (Mint, Sidux etc.) are based on the “testing†and “unstable/experimental†branches of Debian, and with good reason – Debian is VERY stable and secure, plus dpkg (its package manager) is superb. This is why a lot of web servers use the “stable†branch of Debian (and they literally never have to reboot aside from hardware fixes/upgrades). In a nutshell: it’s easy on the eye, and the software which Debian considers “unstable†is still far superior to Windows.
Package Management
When you want a new app in Windows, you’ll probably hunt around on the web for something suitable. Not only is there a lot of malware around, but even some of the well-written and trustworthy apps might not be fully compatible with your system, causing bugs, slowdowns etc. I’m sure you’ve experienced this.
Using a package manager not only means that everything is fully organised/centralised (you can search for, download and install thousands of great apps right from your desktop), but also that everything has to be fully approved for use by the makers of the OS before it becomes available via their main repository (the area of the Debian site that software is downloaded from).
Debian’s testing and approval process is also extremely thorough, and this is one of the many things which still make it one of the most “pure†operating systems available today. The only downside to this is that new versions of Debian are generally only released every couple of years, so the very latest versions of your favourite apps will not be immediately available via dpkg (Debian’s package manager). This is no real reason to be put off, though – you can make some simple system changes to include searches for software in Debian’s “testing†and/or “unstable/experimental†repositories (the same ones Ubuntu’s are based upon). If you’re desperate to use a specific version of a specific app, it’s also possible to add trusted third-party repositories to the list, and of course you can always download things from the web and install them manually.
File Structure
Aside from the swishy GNOME desktop, the first thing you’ll notice with Debian is that the file system is a little different than in Windows. Drives aren’t labelled “C:â€, “D:†and so on, plus you have a “home†directory rather than “My Documentsâ€. The most important areas of most Linux file systems are actually structured like so:
/ – The root directory. Everything starts from here
/bin – System binaries. The core OS files
/etc – System config files
/media – Mounted media. CD drives, USB devices etc.
/usr/bin & /usr/local/bin – User-level applications
/home – Users’ home directories
Anything above /home/*username* requires root access. (When installing Linux you are required to supply a root password as well as the one you wish to use with your user account.)
The Command Line
Most new users notice the command line and assume that it makes things more complicated and difficult. This is simply not true.
When you click icons or move files around in Windows, all you are doing is using a graphical “frontend†to send commands to the OS/apps. With desktops such as GNOME, it really is possible to use Linux without having to use the command line (another frontend) at all, but because you’ve read this far and are therefore clearly not stupid, we’re going to use it anyway. Why? Speed, power and control.
Let’s say we want to install an IRC client. Xchat is a well-established and reliable app, so guaranteed to be in Debian’s main repository. Rather than use “Add/Remove Applications†or the “Synaptic Package Manager†(both perfectly nice GUI frontends), we’re going to go to Applications -> Accessories and open “Terminal†to use APT commands. To install, remove and update things we need to have root access, so we take root by entering
su
then entering the root password when prompted. To download and install (or upgrade to) the latest “stable†version of Xchat, we enter
apt-get install xchat
Wait a moment… Congratulations, you just used APT at the command line to make dpkg download and install a package. We can now run the app by leaving root then entering the name of the packge.
To leave root, type
exit
and to start xchat, enter
xchat
and let the chatting begin. It couldn’t be simpler.
Other APT commands related to this are
apt-get remove *name*
and
apt-get purge *name*
Just remember to take root beforehand and exit root when done (running apps at root is not advised).
Now let’s say we want to download and install something from the web. For Debian, this software might come in the form of .deb packages or .tar.gz archives (a bit like zip/rar files). For this example, we’ll grab the Opera web browser (which is not open-source and therefore not in Debian’s repositories).
.tar.gz
Right-click and extract the file from the tarball just as you would with a zip archive in Windows, then take root and enter the command to change directory to wherever the package is. EG:
cd /home/*username*/opera
You will see the that the command line is pointing at this specific package. Now we need to make sure it’s not going to mess anything up when we compile and install it (highly unlikely).
./configure
All good? Time to compile
make
and install the complied package.
make install
All Done. Now just exit root, run the app and start browsing with Opera. Notice that icons for newly installed apps appear in Taskbar -> Applications -> *category*.
.deb
A .deb file is a package which has already been complied especially for Debian, so this method is even quicker than having to complile it yourself. Take root, change to the relevant directory then enter
dpkg -i *name*.deb
Done. The related remove command here is
dpkg -r *name*
Also, gdebi is a great little tool which allows you to install from a .deb by simply double-clicking. I’m sure you can figure out how to get gdebi by now.
Conclusion
Getting started is not hard, just a little different to what you’re used to, and you don’t even have to use the command line if you don’t want to – I just find it a lot quicker.
Want to give Debian a go? You can download the latest “stable†version for free at http://www.debian.org/distrib/netinst and take look at it using a free Windows app called VirtualBox.
I’ll write about device drivers (â€modulesâ€) soon.
HowTo Build a Package from Source the Smart Way June 21st, 2009
This HowTo is a response to the unlimited supply of terrible advice that I have seen on GNU/Linux forums, on blogs and in various and sundry corners of the internet.
In particular, I wish people would stop advising others to use the make install routine. It’s just as easy — if not easier — to build a DEB. Building a DEB gives you all of the advantages of package management, whereas the make install routine does not.
So this HowTo will describe several different ways that you can build a DEB package. Then — for those of you who insist on using the make install routine — it will explain how to use make install safely.
==================================================================
Before we begin compiling however, let’s review a few compilation basics.
First, you should have a reason for compiling package. There are many valid reasons why you might want to compile a package. The most common reason is to install a more recent version in Debian Stable. If that’s your reason, then take a look around to see if someone has already built a DEB package for you (e.g. Backports). You’ll save yourself a lot of trouble that way.
Another reason is to compile in support for a particular feature. For example, Debian’s most recent version of Gnash uses FFmpeg as its sound handler, but I compiled the same version of Gnash with GStreamer as the sound handler.
In the end, it doesn’t matter what your reason is. Just make sure you have one and make sure it’s a good one.
Second, if you’re using Debian, then you’d be well-advised to use Debian-ized source instead of upstream source because it’s very easy to build a DEB package if you’re using Debianized-source.
If you build and install a DEB, then APT will be aware of the presence of the package and it will make sure that you do not overwrite the files of a previously installed package. By contrast, the make install command will overwrite anything that gets in its way.
==================================================================
Building a DEB is very easy to do and it’s a shame that the members of this forum do not advocate it. If you’ve never built a DEB before, then try building Backintime. It only takes a minute or two, so it’s a great exercise.
In general, building a DEB from Debian-ized source is a simple four-step process.
- First, you add a “source line” to your /etc/apt/sources.list file and install the build dependencies.
- Then you download the source (as normal user).
- Then you run dpkg-buildpackage to build the DEB.
- Finally, you install the DEB(s) with dpkg -i
To be more specific, add the following line to your /etc/apt/sources.list file:
- Code: Select all
- deb-src http://ftp.us.debian.org/debian/ sid main
Then run install the build dependencies:
- Code: Select all
- apt-get update
apt-get install fakeroot
apt-get build-dep <packagename>
Those are the last commands you should run as root before installing the DEB. All of the build commands should be run as normal user.
Next, create a directory for the build in your normal user’s home directory, download the source into that directory and build the DEB:
- Code: Select all
- mkdir /home/XXXX/my_build/
cd /home/XXXX/my_build/
apt-get source <packagename>
cd <packagename>-<version>/
dpkg-buildpackage -rfakeroot -us -uc
That last command may take a minute or an hour or three hours. It all depends on the size of the package and your own hardware.
Once the dpkg-buildpackage command finishes, you’ll find the DEB(s) in your /home/XXXX/my_build/ directory and you can install them (as root) with:
- Code: Select all
- cd /home/XXXX/my_build/
dpkg -i <packagename>_<version>_<architecture>.deb
It doesn’t get much simpler than that.
Perhaps more importantly, a Debian Developer would follow a very similar procedure to create a backport from a package that’s already in Testing or Unstable.
==================================================================
If you’re really eager to compile and there is no Debian-ized source in Unstable or Testing, you can still build a DEB package by using dh-make.
- Code: Select all
- apt-get install fakeroot dh-make
In general, you begin by installing the build dependencies. If you’re building a more recent version of package that’s already in Debian, then the build-dependencies might be the same as the previous version. Otherwise, you’ll have to figure out what they are (by reading the source package’s documentation, for example).
Next, you extract the source into a directory in your home directory as normal user:
- Code: Select all
- mkdir /home/XXXX/my_build/
cd /home/XXXX/my_build/
tar -zxf <packagename>_<version>.tar.gz
Then enter the <packagename>_<version>/ directory and run dh_make.
- Code: Select all
- cd <packagename>_<version>/
dh_make –createorig
dh_make will then ask you if you want to create a: “single binary, multiple binary, library, kernel module or cdbs” and ask you to complete the package maintainer fields.
You might then have to tweak the debian/rules file (e.g. to set configuration options) or set a shell variable. It all depends on the package in question.
Once you have done that (or accepted all of the defaults), then the next step is to run (as normal user):
- Code: Select all
- dpkg-buildpackage
and then install the DEB package (as root) with:
- Code: Select all
- dpkg -i <packagename>_<version>_<architecture>.deb
For a good example of how to use dh-make, see: HowTo Compile PDFedit.
==================================================================
Debian-ized source should be your first choice when building from source. Use dh-make when Debian-ized source is unavailable because it Debian-izes the source for you.
If for some reason Debian-ized source is not available and dh-make doesn’t work, then your third choice should be to use checkinstall.
- Code: Select all
- apt-get install checkinstall
Checkinstall is not as good as the first two options, but at least it produces a DEB, so it will prevent you from unknowingly overwriting system files and it will make APT aware of the package’s presence.
In general, using checkinstall is very similar to the make install routine. The only difference is that you don’t run the make install command.
First, you pick an installation directory. It’s a good idea to pick a directory where no other packages are installed or will be installed. For example, /opt/ or /usr/local/ are two good choices, but because checkinstall will build a DEB, APT will make sure that you don’t overwrite any files even if you choose /usr/ (or if you let the defaults choose /usr/ for you).
Suppose you pick /usr/local/. The next step is to pass that choice to the configure script. For example:
- Code: Select all
- ./configure –prefix=/usr/local –<configuration-options>
Then you would run:
- Code: Select all
- make
su -c checkinstall -D make install
The trouble with checkinstall is that it does not Debian-ize the source or understand package dependencies. It simply keeps track of the files that the DEB contains.
It also annoys me that the files are installed at the same time that the package is built. (That’s why you have to become root to use the checkinstall command). I wish it would just build the DEB and then let me decide when I want to install it.
Nonetheless, it does produce a DEB, so the package can be easily removed and won’t overwrite other files without first obtaining your permission. Just remember to chown it back to your normal user:
- Code: Select all
- chown XXXX:XXXX <packagename>_<version>_<architecture>.deb
==================================================================
If an RPM is available, you might want to look into alien.
- Code: Select all
- apt-get install fakeroot alien
It’s just as bad as checkinstall (because it doesn’t understand package dependencies), but it’s not much worse and — most importantly — it produces a DEB.
To use it, you simply download the RPM and run as normal user:
- Code: Select all
- fakeroot alien -d <packagename>-<version>.<architecture>.rpm
and then become root to install the DEB that alien produces.
- Code: Select all
- dpkg -i <packagename>_<version>_<architecture>.deb
==================================================================
Finally, there’s the make install routine. make install should be your absolute last resort. You should NEVER use it unless all other options have failed and you should ONLY use it IF the package you want to build is of mission critical importance.
The make install routine is the most primitive method of building a package from source and has absolutely no concept of dependencies or package management. There’s a reason why GNU/Linux distributions use package managers like APT or RPM. And that reason is to get as far away from make install as possible.
So if you’re going to use make install, then at least use it intelligently. Do NOT blindly follow the lemmings running off the cliffs of the internet.
As with checkinstall, the most important thing to do is to pick an installation directory where no other packages are installed or will be installed. Once again, /opt/ and /usr/local/ are two good choices.
As with checkinstall, the next step is to pass that choice to the configure script. Suppose (again) that you pick /usr/local/. You would pass that chouce to the configure script with the –prefix flag:
- Code: Select all
- ./configure –prefix=/usr/local –<configuration-options>
That will cause the files to be installed in your /usr/local/ directory, which Debian doesn’t install to by default. This should ensure that you don’t overwrite important system files when you run make install.
The next steps are to build the package and install it:
- Code: Select all
- make
su -c make install
But that’s not the end of the story. If you want to uninstall a package that you installed with the make install routine, then you had better make sure you don’t accidentally delete that package that you compiled (even if it grows to 20 GB) and you had better hope that the its make uninstall routine works just as well as its installation routine or you’ll be stuck manually deleting all of the files.
That’s why you should ALWAYS build a DEB package. Let APT remember where the installed files are. You’ve got better things to do … like play with your newly installed package!
==================================================================
In summary:
- It’s easier to create DEBs from Debianized source than it is to use the make install routine.
- When Debianized source is unavailable, use a helper application to build a DEB, so that you can take advantage of APT’s package management features.
- If you are unable to build a DEB package, then stop and ask yourself if you really need the package you’re trying to build.
- You should ONLY use the make install routine as a LAST RESORT for MISSION CRITICAL applications.
- If you do use the make install routine, do it intelligently.
Good Luck and Have Fun!,
package_version.orig.tar.gz
and then run dh_make, than to try to make dh_make figure it out with –create-orig.
Nice guide! The number of atrocious recommendations on installing packages is absurd.
courtesy to writer and responder and http://forums.debian.net/viewtopic.php?f=16&t=38976
HowTo – Setup DNS (Domain Name Server) using BIND9. June 21st, 2009
by Deja-Vu » 2009-05-15 21:13
This HOWTO will assist you in getting a Domain Name Server (DNS) up and running using BIND9 on Debian Lenny. When setting up a DNS server it is common practise to use two separate DNS servers for a domain as you are required to have at least two DNS servers running for DNS to work correctly. If one breaks, the other can continue to serve your domain.
However, when I setup my DNS system I did not have the resources on hand to use two different servers for DNS so the setup below will configure one server to run both nameservers. It’s not an ideal solution and is definitely not a best practise solution but one can only work with what you have.
Run BIND in a “chroot” jail, so it is much more difficult for a compromised bind daemon to damage the operating system or compromise other services.
In this HOWTO I will use the fictional domain “sampledns.com”. The nameservers will use 192.168.254.1 and 192.168.254.2 as their IP addresses. Both the domain and namerserver IPs need to be changed to reflect your server details.
Requirements
A Debian Lenny base installation.
At least two static IP addresses that you can use to setup the nameserver information.
Root access to your server.
Pre-Installation notes: (You need to be in the root terminal from here on to the end of this HowTo)
Before proceeding to install, update the necessary packages in Debian with these commands.
- Code: Select all
- apt-get update
and
- Code: Select all
- apt-get upgrade
Installing lsb-base and BIND9
To continue we need some Debian building tools since we are going to download source packages:
- Code: Select all
- apt-get install devscripts
The next two steps were put into 2 seperate code windows to shorten the HowTo a bit since it’s rather lenghy. Each command should be run on a seperate line if not only for the simple reason you can see and deal with any errors that may be presented without having to go back and search logs.
BIND9 depends on lsb-base: (Syntax explanation: the -y tells apt to say yes to all questions, build-dep installs all packages required for -packageX- from the repository and with -b the source gets built straight away.)
- Code: Select all
- mkdir /usr/local/lsb-base/
cd /usr/local/lsb-base/
apt-get -y build-dep lsb-base
apt-get source lsb-base -b
dpkg -i lsb-base*.deb
Next is BIND9:
- Code: Select all
- mkdir /usr/local/bind9
cd /usr/local/bind9
apt-get -y build-dep bind9
apt-get source bind9 -b
dpkg -i *.deb
Configure the Master DNS Server
First we need to stop BIND9:
- Code: Select all
- /etc/init.d/bind9 stop
In order to chroot bind we need to set an option in /etc/default/bind9.
Locate this in /etc/default/bind9:
- Code: Select all
- vim /etc/default/bind9
OPTIONS=”-u bind”
Replace it with this:
- Code: Select all
- OPTIONS=”-u bind -t /var/lib/named”
It will now run as user ‘bind’ chrooted in ‘/var/lib/named’.
These steps are required for the chroot jail: (Recommend running each command on a seperate line)
- Code: Select all
- mkdir -p /var/lib/named/etc
mkdir /var/lib/named/dev
mkdir -p /var/lib/named/var/cache/bind
mkdir -p /var/lib/named/var/run/bind/run
mv /etc/bind /var/lib/named/etc
ln -s /var/lib/named/etc/bind /etc/bind
mknod /var/lib/named/dev/null c 1 3
mknod /var/lib/named/dev/random c 1 8
chmod 666 /var/lib/named/dev/*
chown -R bind:bind /var/lib/named/var/*
chown -R bind:bind /var/lib/named/etc/bind
Bind now has its own dir with space for .pid files and config files. In order to keep things clear we made a symlink back to /etc/.
NOTE: In this next step i ran into a problem where sysklogd was not installed for some reason on one the systems i installed the DNS on.
To Fix:
- Code: Select all
- apt-get install sysklogd
it will either tell you that you have the latest version or install it with dependencies.
Now edit /etc/init.d/sysklogd to allow logging of bind activity.
- Code: Select all
- vim /etc/init.d/sysklogd
Replace this:
SYSLOGD=”"
With this:
- Code: Select all
- SYSLOGD=”-a /var/lib/named/dev/log”
Now restart sysklogd and BIND9:
- Code: Select all
- /etc/init.d/sysklogd restart
- Code: Select all
- /etc/init.d/bind9 start
And test:
ping http://www.google.com (NOTE: to stop the ping outputs hit the ctrl + c key, we do not want to packet flood google)
If you get a reply, then your DNS master server is working and ready to use. To complete and use the sampledns.com domain with your new master server. (IMPORTANT: Remember to replace sampledns.com and 192.168.254.1 with your domain information)
Create the zone files:
Start with creating the directory where you will store the zone file.
- Code: Select all
- mkdir /etc/bind/zones/master/
Now create the zones file: (This file contains all information about the domain)
- Code: Select all
- vim /etc/bind/zones/master/sampledns.com.db
Add the following (NOTE:replacing sampledns.com and 192.168.254.1 with your own details):
- Code: Select all
- ;
; BIND data file for sampledns.com
;
$TTLÂ Â 604800
@Â Â Â Â INÂ Â Â SOAÂ Â Â sampledns.com. info.sampledns.com. (
2009051501Â Â Â Â Â ; Serial
7200Â Â Â Â Â ; Refresh
120Â Â Â Â Â ; Retry
2419200Â Â Â Â Â ; Expire
604800)Â Â Â Â ; Default TTL
;
@Â Â Â Â INÂ Â Â Â NSÂ Â ns1.sampledns.com.
@Â Â Â Â INÂ Â Â Â NSÂ Â ns2.sampledns.com.
sampledns.com.  IN  MX   10   mail.sampledns.com.
sampledns.com.  IN  A    192.168.254.1
www           IN   CNAME  sampledns.com.
mail          IN   A    192.168.254.1
ftp           IN   CNAME  sampledns.com.
sampledns.com.     IN   TXT   ”v=spf1 ip4:192.168.254.1 a mx ~all”
mail          IN   TXT   ”v=spf1 a -all”
Here we have created a DNS zone file with both nameservers as well as records for the mail and ftp server for the domain sampledns.com. Trying to go into more detail about what each item reflects above is beyond the scope of this HOWTO and you should do your own research into what each item means.
In South Africa registering domain names with the .co.za extension requires that Reverse DNS (RDNS) is setup correctly. Other TLD’s don’t necessarily require RDNS but either way it’s good practise to setup RDNS for your DNS server so we’ll do so now.
Create a new file called 192.168.254.rev which follows the convention of the first three IP ranges in your IP address:
- Code: Select all
- vim /etc/bind/zones/master/192.168.254.rev
Add the following: (NOTE:replacing ns1.sampledns.com, info.sampledns.com and ns2.sampledns.com with your own details):
- Code: Select all
- $TTL 1d ;
$ORIGIN 254.168.192.IN-ADDR.ARPA.
@    IN   SOA   ns1.sampledns.com.  info.sampledns.com. (
2009051501
7200
120
2419200
604800
)
INÂ Â Â NSÂ Â Â ns1.sampledns.com.
INÂ Â Â NSÂ Â Â ns2.sampledns.com.
1Â Â Â Â INÂ Â Â PTRÂ Â Â ns1.sampledns.com.
2Â Â Â Â INÂ Â Â PTRÂ Â Â ns2.sampledns.com.
The reverse lookup files are almost identical to the domain zone files with only minor changes. The first section of this file is exactly the same as the first section of the domain zone file. The bottom section is where it is different. This time we are listing the last part of the IP address first and then the hostname last.
There are 2 IMPORTANT things you must observe here. You have to use the fully qualified domain name here and you must put a “.” at the end of it. These 2 things are important to the file and weird things happen if you do not do it exactaly this way.
You must also change the $ORIGIN section at the top of the RDNS file to reflect the reverse IP address of your server. In this sample our IP address ranges are 192.168.254.1/2 and the reverse of this would be 254.168.192.IN-ADDR.ARPA. In the PTR records at the bottom we assign the final IP range to reflect our two nameservers – i.e. 1 & 2.
Making sure everything is OK-
Now that we have created both zone and reverse files. Now we need to check that our main zone file is good to go. BIND9 breaks very easily so it’s best to run this check before committing your changes.
- Code: Select all
- cd /etc/bind/zones/master/
Then run:
- Code: Select all
- named-checkzone sampledns.com sampledns.com.db
You should get an OK status when doing this. If not you need to double check your zone file and make changes until you get an OK status.
Adding zone files to BIND9
We now need to add the zone file data to the named.conf.local file:
- Code: Select all
- vim /etc/bind/named.conf.local
And add the following to the file: (Replacing sampledns.com with your details)
- Code: Select all
- zone “sampledns.com” {
type master;
file “/etc/bind/zones/master/sampledns.com.db”;
};zone “254.168.192.IN-ADDR.ARPA” {
type master;
file “/etc/bind/zones/master/192.168.254.rev”;
};
Testing
We can now restart bind and check if it works: (don’t forget to replace ns1.sampledns.com with your details)
/etc/init.d/bind9 restart
ping ns1.sampledns.com
This should bring bring up a ping result resolving to 192.168.254.1
Try another test:
nslookup ns1.sampledns.com
Should give you 192.168.254.1
Finally run this one:
dig @localhost sampledns.com
If all is OK then you’ll be presented with the zone file information.
At this point you now have a working and usable DNS server.
Troubleshooting
If you’re wondering why updates to the zone file on your master seem to fail, check the serial number inside the zone file. Each time you make a change to the zone file you will need to increase the Serial number in the zone file to ensure that your latest changes are updated.
The serial number is setup and constructed as follows:
2009051501 = (2007)(05)(15)(01)
First 4 digits of the serial indicate the year – i.e. 2009
Next 2 digits of the serial indicate the month – i.e. 05 (May)
Next 2 digits of the serial indicate the date – i.e. 15
The last 2 digits of the serial indicate the revision number for that day – i.e. 01
If you are updating your Serial number but your changes are not being reflected I suggest that you reload your BIND data by executing the following command in a Linux shell:
- Code: Select all
- rndc reload
If you are running BIND on two different servers you will need to install ntpdate on both servers to ensure that zone transfers happen correctly. Both master and slave servers need to have the exact same time setting for zone transfers to take place:
apt-get -y install ntpdate
coutesy Deja-Vu and http://forums.debian.net/viewtopic.php?f=16&t=39146
