1 Jun
2011
1 Jun
'11
11:34 a.m.
Hi everyone,
I have decided to venture down what I hope is a well trodden path by now;
upgrading my VPS from Debian Lenny to Squeeze.
I have scoured the list archives and tried to make the most of
http://www.debian.org/releases/squeeze/i386/release-notes/ch-upgrading.en.h…
however I'm not ashamed to admit that I'm no expert in this regard and
very much still learning so would appreciate a critique of my plan of
action:
- Ask Support kindly to perform a temporary disk snapshot
- Login via Xen console
- Verify no pending actions required for currently installed packages:
aptitude (Then hit 'g' once in 'visual mode')
- Verify that all packages are in an upgradable state:
dpkg --audit
- Show currently installed kernel(s):
dpkg -l | grep linux-image
Mine currently shows:
ii linux-image-2.6-xen-686 2.6.26+17+lenny1 Linux 2.6 image on
i686, oldstyle Xen suppor
ii linux-image-2.6.26-1-xen-686 2.6.26-13lenny2 Linux 2.6.26
image on i686, oldstyle Xen sup
ii linux-image-2.6.26-2-xen-686 2.6.26-26lenny2 Linux 2.6.26
image on i686, oldstyle Xen sup
- Confirm non-usage of grub2:
dpkg -l | grep grub
Mine currently shows:
ii grub 0.97-47lenny2 GRand Unified Bootloader (Legacy version)
ii grub-common 1.96+20080724-16 GRand Unified Bootloader, version
2 (common
- Updates apt sources lists from lenny to squeeze:
sed -i s/lenny/squeeze/g /etc/apt/sources.list
- Manually edit /etc/apt/source.list to confirm success of the above step
and comment out any other repositories (non-Debian, backports etc) ?
- Upgrade the kernel: (*** Am I aiming for the right one here? ***)
aptitude install linux-image-2.6-686-bigmem
- Update grub configuration:
update-grub
- Remove clocksource=jiffies from kopt directive in /boot/grub/menu.lst
and confirm correct kernel will be loaded (i.e. default # matches new
kernel position)
- Upgrade udev (to minimise the risk of running the old udev with the new
kernel):
apt-get install udev
- Reboot
- Record a transcript of the upgrade session:
script -t 2>~/upgrade-squeeze.time -a ~/upgrade-squeeze.script
(This can be reviewed at a later date with scriptreplay
~/upgrade-squeeze.time ~/upgrade-squeeze.script)
- Update the package list:
apt-get update
- Perform a minimal upgrade (i.e. upgrade those packages that don't
require installation/removal of any other package(s)):
apt-get upgrade
- Complete the rest of the upgrade:
apt-get dist-upgrade
- Remove old/obsolete packages no longer required:
apt-get autoremove
- (Hopefully:) After the dust settles, advise Support that the snapshot of
the old system can be removed
Hope does that all look? Please don't hold back...
Regards,
Mathew
1 Jun
1 Jun
1:52 p.m.
Hi Mathew,
On 1 June 2011 12:34, Mathew Newton <bitfolklist(a)newtonnet.co.uk> wrote:
I have decided to venture down what I hope is a well
trodden path by now;
upgrading my VPS from Debian Lenny to Squeeze.
I have scoured the list archives and tried to make the most of
http://www.debian.org/releases/squeeze/i386/release-notes/ch-upgrading.en.h…
however I'm not ashamed to admit that I'm no expert in this regard and
very much still learning so would appreciate a critique of my plan of
action:
[snipped]
Thanks a lot for sharing. I'm in a similar position, with one VPS
running Lenny, and one running Etch (argh!) May I suggest
https://tools.bitfolk.com/wiki/Guides
as a potentially suitable home for this useful information? It could
then be honed by multiple contributors.
Cheers,
Adam
9:57 p.m.
Hi Mathew,
It all looks okay (so I won't quote it all).
One thing I would say is that you probably want to make sure that
your block devices are just xvda, xvdb, etc. instead of xvda1,
xvda2, etc. Otherwise you will run into difficulties doing
"update-grub" after installing squeeze's kernel.
Fixing this involves you making sure that your VPS will boot by
LABEL or UUID, us shutting your VPS down, changing its config to use
xvda, xvdb, etc., and then booting it again for you.
Cheers,
Andy
--
http://bitfolk.com/ -- No-nonsense VPS hosting
10:14 p.m.
Thanks Andy, and you others, for the comments.
One thing I would say is that you probably want to
make sure that
your block devices are just xvda, xvdb, etc. instead of xvda1,
xvda2, etc. Otherwise you will run into difficulties doing
"update-grub" after installing squeeze's kernel.
I've just discovered an old post of yours
(http://lists.bitfolk.com/lurker/message/20080529.142153.954fedf4.el.html)
which is presumably what this issue is about. I've checked my
/boot/grub/device.map and it confirms xvda (and kopt in
/boot/grub/menu.lst uses a UUID).
When I get round to giving this a go I'll feed back to the list with how
the proposed steps went. Hopefully I'll be more confident in them then and
could perhaps put them on the Wiki if deemed useful (at least as a
starting point for further fleshing out).
Mathew
10:28 p.m.
Hi Mathew,
On Wed, Jun 01, 2011 at 11:14:53PM +0100, Mathew Newton wrote:
Thanks Andy, and you others, for the comments.
By the time you have the squeeze version of update-grub though, none
of those workarounds will work. You absolutely have to have either a
filesystem directly on /dev/xvda, or a partitioned disk at
/dev/xvda. I haven't yet looked to see if this is the case for you.
Cheers,
Andy
--
http://bitfolk.com/ -- No-nonsense VPS hosting
One thing I would say is that you probably want
to make sure that
your block devices are just xvda, xvdb, etc. instead of xvda1,
xvda2, etc. Otherwise you will run into difficulties doing
"update-grub" after installing squeeze's kernel.
I've just discovered an old post of yours
(http://lists.bitfolk.com/lurker/message/20080529.142153.954fedf4.el.html)
which is presumably what this issue is about. I've checked my
/boot/grub/device.map and it confirms xvda (and kopt in
/boot/grub/menu.lst uses a UUID).
10:36 p.m.
Hi Andy,
By the time you have the squeeze version of
update-grub though, none
of those workarounds will work. You absolutely have to have either a
filesystem directly on /dev/xvda, or a partitioned disk at
/dev/xvda.
Ah, okay. I think I may have got the wrong end of the stick. At the risk
of grabbing the 3rd end, my output of mount gives:
/dev/xvda on / type ext3 (rw,relatime)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
Presumably this means I'm okay. Forgive all my guessing here - it must be
terribly frustrating to someone who has a decent understanding of all of
this!
I haven't yet looked to see if this is the case
for you.
If you're able to that'd be appreciated, however I certainly don't expect
it as I know your role here is not providing free technical support to
numpties like me!
Mathew
10:46 p.m.
Hi Mathew,
On Wed, Jun 01, 2011 at 11:36:19PM +0100, Mathew Newton wrote:
/dev/xvda on / type ext3 (rw,relatime)
That's fine. It would say /dev/xvda1 if there were a problem.
Cheers,
Andy
--
http://bitfolk.com/ -- No-nonsense VPS hosting
7 Aug
7 Aug
7:52 p.m.
On 01/06/11 23:46, Andy Smith wrote:
Hi Mathew,
On Wed, Jun 01, 2011 at 11:36:19PM +0100, Mathew Newton wrote:
I'm just embarking on the lenny to squeeze update and have the same
output to the mount command as Matthew.
My question is regarding replacing labels by UUID's. Output of cat
/etc/fstab:
LABEL=root / ext3 defaults,relatime 0 1
/var/lib/swapfile swap swap defaults 0 0
proc /proc proc defaults,noexec,nosuid 0 0
Output of blkid:
/dev/xvda1: LABEL="/" UUID="09dd100a-4bfa-47c5-9c3e-559068bafb2c"
TYPE="ext3"
/dev/xvda2: UUID="195f7eaf-ec5e-4e3c-92d3-c0171200ff00" TYPE="swap"
/dev/xvda: LABEL="root" UUID="814d97eb-aee6-4af0-bc94-eb56188b65b5"
TYPE="ext3"
Which UUID do I use in fstab - just LABEL="root"
UUID=814d97eb-aee6-4af0-bc94-eb56188b65b5 in place of LABEL=root or the
UUID's for /dev/xvda1 and /dev/xvda2 in place of LABEL=root and
/var/lib/swapfile
Guidance appreciated.
Regards, Martin
/dev/xvda on / type ext3 (rw,relatime)
That's fine. It would say /dev/xvda1 if there were a problem.
Cheers,
Andy
7:59 p.m.
Hi Martin,
On Sun, Aug 07, 2011 at 08:52:39PM +0100, Martin Halford wrote:
My question is regarding replacing labels by
UUID's. Output of cat
/etc/fstab:
LABEL=root / ext3 defaults,relatime 0 1
/var/lib/swapfile swap swap defaults 0 0
proc /proc proc defaults,noexec,nosuid 0 0
Output of blkid:
/dev/xvda1: LABEL="/" UUID="09dd100a-4bfa-47c5-9c3e-559068bafb2c"
TYPE="ext3"
/dev/xvda2: UUID="195f7eaf-ec5e-4e3c-92d3-c0171200ff00" TYPE="swap"
/dev/xvda: LABEL="root" UUID="814d97eb-aee6-4af0-bc94-eb56188b65b5"
TYPE="ext3"
I'm a bit confused by the fact that blkid sees both xvda and xvda1,
and that it thinks there is swap on xvda2 and well as on a swap file.
What is the output of "cat /proc/mounts" please?
Cheers,
Andy
8:14 p.m.
On 07/08/11 20:59, Andy Smith wrote:
Hi Martin,
On Sun, Aug 07, 2011 at 08:52:39PM +0100, Martin Halford wrote:
Andy,
cat /proc/mounts
rootfs / rootfs rw 0 0
none /sys sysfs rw,nosuid,nodev,noexec 0 0
none /proc proc rw,nosuid,nodev,noexec 0 0
udev /dev tmpfs rw,size=10240k,mode=755 0 0
/dev/disk/by-label/root / ext3 rw,relatime,errors=continue,data=ordered 0 0
tmpfs /lib/init/rw tmpfs rw,nosuid,mode=755 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
devpts /dev/pts devpts rw,nosuid,noexec,gid=5,mode=620 0 0
Thanks, Martin
My question is regarding replacing labels by
UUID's. Output of cat
/etc/fstab:
LABEL=root / ext3 defaults,relatime 0 1
/var/lib/swapfile swap swap defaults 0 0
proc /proc proc defaults,noexec,nosuid 0 0
Output of blkid:
/dev/xvda1: LABEL="/" UUID="09dd100a-4bfa-47c5-9c3e-559068bafb2c"
TYPE="ext3"
/dev/xvda2: UUID="195f7eaf-ec5e-4e3c-92d3-c0171200ff00" TYPE="swap"
/dev/xvda: LABEL="root" UUID="814d97eb-aee6-4af0-bc94-eb56188b65b5"
TYPE="ext3"
I'm a bit confused by the fact that blkid sees both xvda
and xvda1,
and that it thinks there is swap on xvda2 and well as on a swap file.
What is the output of "cat /proc/mounts" please?
Cheers,
Andy
8:22 p.m.
Hi Martin,
On Sun, Aug 07, 2011 at 09:14:27PM +0100, Martin Halford wrote:
/dev/disk/by-label/root / ext3
rw,relatime,errors=continue,data=ordered 0 0
Okay so your root is really the one labelled "root", it's on
/dev/xvda, and your swap is coming from the swap file.
I don't know why blkid finds xvda1 and xvda2.
Cheers,
Andy
8:28 p.m.
On 07/08/11 21:22, Andy Smith wrote:
Hi Martin,
On Sun, Aug 07, 2011 at 09:14:27PM +0100, Martin Halford wrote:
So /etc/fstab becomes:
UUID=814d97eb-aee6-4af0-bc94-eb56188b65b5 / ext3
defaults,relatime 0 1
/var/lib/swapfile swap swap defaults 0 0
proc /proc proc defaults,noexec,nosuid 0 0
I'll give it a go!
Thanks, Martin
/dev/disk/by-label/root / ext3
rw,relatime,errors=continue,data=ordered 0 0
Okay so your root is really the one
labelled "root", it's on
/dev/xvda, and your swap is coming from the swap file.
I don't know why blkid finds xvda1 and xvda2.
Cheers,
Andy
8 Aug
8 Aug
8:04 p.m.
On 07/08/11 21:33, Andy Smith wrote:
Hi Martin,
On Sun, Aug 07, 2011 at 09:28:35PM +0100, Martin Halford wrote:
Following Wiki article:
https://tools.bitfolk.com/wiki/Upgrading_your_Debian_VPS_from_lenny_to_sque…
"Recommended: Move to UUIDs in /etc/fstab and /boot/grub/menu.list
(kernel and kopt lines) if that isn't already the case".
Maybe not necessary from your comment?
Regards, Martin
> So /etc/fstab becomes:
>
> UUID=814d97eb-aee6-4af0-bc94-eb56188b65b5 / ext3
Why not leave it as
LABEL=root?
8:10 p.m.
Hi Martin,
On Mon, Aug 08, 2011 at 09:04:30PM +0100, Martin Halford wrote:
On 07/08/11 21:33, Andy Smith wrote:
Ah OK. Yeah I'd say LABEL is equally good, Whatever you prefer. The
point is to not have hard coded device paths.
Cheers,
Andy
Why not leave it as LABEL=root?
Following Wiki article:
https://tools.bitfolk.com/wiki/Upgrading_your_Debian_VPS_from_lenny_to_sque…
"Recommended: Move to UUIDs in /etc/fstab and /boot/grub/menu.list
(kernel and kopt lines) if that isn't already the case".
Maybe not necessary from your comment?
9 Aug
9 Aug
10:23 p.m.
On 08/08/11 21:10, Andy Smith wrote:
Ah OK. Yeah I'd say LABEL is equally good,
Whatever you prefer. The
point is to not have hard coded device paths.
I completed my upgrade from lenny to squeeze last night using a
combination of the wiki page, the archives of this list and the Debian
documentation.
The only problem I had of any significance was with Dovecot, which was
not delivering mail to virtual users after the upgrade. The problem was
to do with a change to the cmusieve plugin in Dovecot .
[Taken from a recent forum post] The protocol "managesieve" is now
called "lda" and the plugin "cmusieve" is called "sieve"
from V1.2 of
Dovecot.
So you have to replace this in dovecot.conf :
protocol managesieve {
By :
protocol lda {
And:
mail_plugins = cmusieve quota
(be careful : it's the mail_plugins directive INSIDE THE "protocol lda {" )
By:
mail_plugins = sieve quota
After restarting Dovecot, mail delivery resumed (to my relief!)
Might be useful to someone?
Regards, Martin
15 Jan
15 Jan
8:59 p.m.
Five months ago Martin Halford said:
The only problem I had of any significance was with
Dovecot, which was
not delivering mail to virtual users after the upgrade. The problem was
to do with a change to the cmusieve plugin in Dovecot .
[Taken from a recent forum post] The protocol "managesieve" is now
called "lda" and the plugin "cmusieve" is called "sieve"
from V1.2 of
Dovecot.
Having finally got around to doing the upgrade before Lenny security
updates stop, yes, this caught me.
Commenting out two lines in protocol managesieve {
# sieve=~/.dovecot.sieve
# sieve_storage=~/sieve
seems to have done the trick.
Other issues:
1. postgrey (does greylisting for postfix) now listens on a different
port (10023 not 60000) so /etc/postfix/main.cf needs changing to reflect
that.
2. You can only install grub-legacy after doing the dist-upgrade, i.e.
after it has moaned about issues with grub2.
3. MySQL 5.0 is declared removable, but 5.1 is not automatically
installed in its place. Doing the upgrade via
apt-get install mysql-server-5.1
before the dist-upgrade works.
4. Doing the upgrade via the console had an issue with some of the alert
boxes ('you've made changes to this file - do you want to keep them or
install the package maintainer's version' sort of thing) staying on
screen. Towards the end, I had one viewable line of text.
5. suphp didn't work afterwards on the first VPS. This turns out to be
changes to the syntax in /etc/suphp/suphp.conf and accepting the new
version seems to have been ok in the second
6. The oddity common to both is that although BIND9 is up and running..
/etc/init.d/bind9 status
bind9 is running.
.. and it's doing zone transfers, the BIND Webmin 1.570 module doesn't
seem to think that it is. Instead of the usual options to
Apply configuration
or
Stop BIND
.. there's
Start BIND
instead. Does anyone else use Webmin?
Ian
16 Jan
16 Jan
9:44 a.m.
Hi Ian,
On Sun, January 15, 2012 8:59 pm, Ian wrote:
4. Doing the upgrade via the console had an issue with
some of the alert
boxes ('you've made changes to this file - do you want to keep them or
install the package maintainer's version' sort of thing) staying on
screen. Towards the end, I had one viewable line of text.
That's interesting - I see that all the time in the console and assumed it
was something to do with the configuration at my end (accessing via
Putty).
For normal scrolling text I don't have any problems with the console,
however when editing in-situ e.g. with nano/emacs the screen often starts
to freeze and the effective text window decreases until I have no choice
but to disconnect and try again.
It is little more than a pain at the moment, however I was planning an
Lenny-to-Squeeze upgrade and am concerned now as I really don't want any
issues like this mid way.
Has anyone else seen this and/or got any ideas how to resolve it?
Mathew
P.S. I could probably take a video of the problem if it helps show what
the issue is...
12:52 p.m.
On Mon, Jan 16, 2012 at 09:44:57AM -0000, Mathew Newton wrote:
Hi Ian,
On Sun, January 15, 2012 8:59 pm, Ian wrote:
dpkg-reconfigure -plow debconf doesn't help if you configure it to use dialog
or something that should fit your terminal ?
Thanks,
Rodrigo
4. Doing the upgrade via the console had an issue
with some of the alert
boxes ('you've made changes to this file - do you want to keep them or
install the package maintainer's version' sort of thing) staying on
screen. Towards the end, I had one viewable line of text.
That's interesting - I see that all the time in the console and assumed it
was something to do with the configuration at my end (accessing via
Putty).
For normal scrolling text I don't have any problems with the console,
however when editing in-situ e.g. with nano/emacs the screen often starts
to freeze and the effective text window decreases until I have no choice
but to disconnect and try again.
It is little more than a pain at the moment, however I was planning an
Lenny-to-Squeeze upgrade and am concerned now as I really don't want any
issues like this mid way.
Has anyone else seen this and/or got any ideas how to resolve it? 
1:04 p.m.
On 16/01/12 13:52, Rodrigo Campos wrote:
On Mon, Jan 16, 2012 at 09:44:57AM -0000, Mathew
Newton wrote:
I believe the problem is that in a xen-console you get a "linux"-type
terminal, which appears to be rather limited.
$ echo $TERM
while in the console returns "linux" at least in my private xen-setup.
I don't know if it is possible to change this.
- OM
Hi Ian,
On Sun, January 15, 2012 8:59 pm, Ian wrote:
dpkg-reconfigure -plow debconf doesn't help if you configure it to use dialog
or something that should fit your terminal ? 4. Doing the upgrade via the console had an issue
with some of the alert
boxes ('you've made changes to this file - do you want to keep them or
install the package maintainer's version' sort of thing) staying on
screen. Towards the end, I had one viewable line of text.
That's interesting - I see that all the time in the console and assumed it
was something to do with the configuration at my end (accessing via
Putty).
For normal scrolling text I don't have any problems with the console,
however when editing in-situ e.g. with nano/emacs the screen often starts
to freeze and the effective text window decreases until I have no choice
but to disconnect and try again.
It is little more than a pain at the moment, however I was planning an
Lenny-to-Squeeze upgrade and am concerned now as I really don't want any
issues like this mid way.
Has anyone else seen this and/or got any ideas how to resolve it? 
5:25 p.m.
As a temporary fix you could just:
$ export TERM=xterm
Though that'd only persist until you logout/back in.
--
Aaron B. Russell
email: aaron(a)unadopted.co.uk
web: http://unadopted.co.uk
music: http://unadopted.co.uk/podcast
blog: http://lostentropy.com
tel: +44 20 3137 4147
On Monday, January 16, 2012 at 1:04pm, Ole-Morten Duesund wrote:
On 16/01/12 13:52, Rodrigo Campos wrote:
On Mon, Jan 16, 2012 at 09:44:57AM -0000, Mathew
Newton wrote:
I believe the problem is that in a xen-console you get a "linux"-type
terminal, which appears to be rather limited.
$ echo $TERM
while in the console returns "linux" at least in my private xen-setup.
I don't know if it is possible to change this.
- OM
_______________________________________________
users mailing list
users(a)lists.bitfolk.com (mailto:users@lists.bitfolk.com)
https://lists.bitfolk.com/mailman/listinfo/users
Hi Ian,
On Sun, January 15, 2012 8:59 pm, Ian wrote:
dpkg-reconfigure -plow debconf doesn't help if you configure it to use dialog
or something that should fit your terminal ?
4. Doing the upgrade via the console had an issue
with some of the alert
boxes ('you've made changes to this file - do you want to keep them or
install the package maintainer's version' sort of thing) staying on
screen. Towards the end, I had one viewable line of text.
That's interesting - I see that all the time in the console and assumed it
was something to do with the configuration at my end (accessing via
Putty).
For normal scrolling text I don't have any problems with the console,
however when editing in-situ e.g. with nano/emacs the screen often starts
to freeze and the effective text window decreases until I have no choice
but to disconnect and try again.
It is little more than a pain at the moment, however I was planning an
Lenny-to-Squeeze upgrade and am concerned now as I really don't want any
issues like this mid way.
Has anyone else seen this and/or got any ideas how to resolve it?
7:58 p.m.
On Mon, Jan 16, 2012 at 05:25:59PM +0000, Aaron B. Russell wrote:
As a temporary fix you could just:
$ export TERM=xterm
Though that'd only persist until you logout/back in.
The problem with that is that the underlying terminal-code presumably
only supports "linux" and not "xterm", whatever the differences may
be.
I suspect the only way to really fix this lies somewhere in the Xen
codebase.
- OM
On Monday, January 16, 2012 at 1:04pm, Ole-Morten
Duesund wrote:
--
In the first place, God made idiots; this was for practice; then he made
school boards.
-- Mark Twain
On 16/01/12 13:52, Rodrigo Campos wrote:
On Mon, Jan 16, 2012 at 09:44:57AM -0000, Mathew
Newton wrote:
I believe the problem is that in a xen-console you get a "linux"-type
terminal, which appears to be rather limited.
$ echo $TERM
while in the console returns "linux" at least in my private xen-setup.
I don't know if it is possible to change this.
- OM
_______________________________________________
users mailing list
users(a)lists.bitfolk.com (mailto:users@lists.bitfolk.com)
https://lists.bitfolk.com/mailman/listinfo/users
Hi Ian,
On Sun, January 15, 2012 8:59 pm, Ian wrote:
> 4. Doing the upgrade via the console had an issue with some of the alert
> boxes ('you've made changes to this file - do you want to keep them or
> install the package maintainer's version' sort of thing) staying on
> screen. Towards the end, I had one viewable line of text.
>
That's interesting - I see that all the time in the console and assumed it
was something to do with the configuration at my end (accessing via
Putty).
For normal scrolling text I don't have any problems with the console,
however when editing in-situ e.g. with nano/emacs the screen often starts
to freeze and the effective text window decreases until I have no choice
but to disconnect and try again.
It is little more than a pain at the moment, however I was planning an
Lenny-to-Squeeze upgrade and am concerned now as I really don't want any
issues like this mid way.
Has anyone else seen this and/or got any ideas how to resolve it?
dpkg-reconfigure -plow debconf doesn't help if you configure it to use dialog
or something that should fit your terminal ?
25 Jan
25 Jan
3:17 p.m.
I said...
6. The oddity common to both is that although BIND9 is
up and running..
Ah ha. Having found
<http://forums.rimuhosting.com/forums/showthread.php?t=498>, it appears
Webmin is looking in the wrong place (and despite having had an upgrade
in the last few days, the webmin.com version at least is still doing it
a year or so after Squeeze's release!)
Editing the pid_file line in /etc/webmin/bind8/config to
pid_file=/var/run/named/named.pid /var/run/named.pid
works.
Fortunately, I don't seem to have had the other problems mentioned there.
Ian
/etc/init.d/bind9 status
bind9 is running.
.. and it's doing zone transfers, the BIND Webmin 1.570 module doesn't
seem to think that it is. Instead of the usual options to
Apply configuration
or
Stop BIND
.. there's
Start BIND
instead. Does anyone else use Webmin?
4714
days inactive
4952
days old
23 comments
8 participants
participants (8)
-
Aaron B. Russell -
Adam Spiers -
Andy Smith -
Ian -
Martin Halford -
Mathew Newton -
Ole-Morten Duesund -
Rodrigo Campos