on the
mysql..??
Thank you ,
David J.
- Original Message -
From: Eric Shubes [EMAIL PROTECTED]
To: qmailtoaster-list@qmailtoaster.com
Sent: Friday, February 02, 2007 11:10 PM
Subject: Re: [qmailtoaster] Upgrade Script
David J. wrote:
Dear All,
Is it safe to use the upgrade
-list@qmailtoaster.com
Sent: Friday, February 02, 2007 11:10 PM
Subject: Re: [qmailtoaster] Upgrade Script
David J. wrote:
Dear All,
Is it safe to use the upgrade script from
http://www.qmailtoaster.com/info/upgrade.sh to upgrade my current
qmailtoaster ..??
Does it keep my current
]
To: qmailtoaster-list@qmailtoaster.com
Sent: Monday, February 05, 2007 10:43 AM
Subject: Re: [qmailtoaster] Upgrade Script
David J. wrote:
Dear Shubes,
Thank you very much on your reply, I'll try to look on your URL link.
So upgrading won't change my vpopmail users and domains right ..?
Right
work on the qmt projects.
Regards,
David J.
- Original Message - From: Eric Shubes [EMAIL PROTECTED]
To: qmailtoaster-list@qmailtoaster.com
Sent: Monday, February 05, 2007 10:43 AM
Subject: Re: [qmailtoaster] Upgrade Script
David J. wrote:
Dear Shubes,
Thank you very
David J. wrote:
Dear All,
Is it safe to use the upgrade script from
http://www.qmailtoaster.com/info/upgrade.sh to upgrade my current
qmailtoaster ..??
Does it keep my current configuration, domains, users, password and it's
mails afterward..?? or there are things that I should do
Eric Shubes wrote:
I wouldn't use it. I don't know if anyone's maintaining it or not. If not,
then it won't work (it doesn't include libsrs2-toaster which is now required).
I'd use qtp-newmodel. It's robust and simple. It'll upgrade your toaster to
the latest ones including letting you
Ed Morrison wrote:
Eric Shubes wrote:
I wouldn't use it. I don't know if anyone's maintaining it or not. If
not,
then it won't work (it doesn't include libsrs2-toaster which is now
required).
I'd use qtp-newmodel. It's robust and simple. It'll upgrade your
toaster to
the latest ones
Eric Shubes wrote:
This is true. I'm working on that, but the fix is not trivial.
In the meantime, simply do not select djbdns for upgrading, and qtp-newmodel
will upgrade the rest of the packages just fine (AFAIK). djbdns has not
functionally changed. It only has a new release number to
Ed Morrison wrote:
Eric Shubes wrote:
This is true. I'm working on that, but the fix is not trivial.
In the meantime, simply do not select djbdns for upgrading, and
qtp-newmodel
will upgrade the rest of the packages just fine (AFAIK). djbdns has not
functionally changed. It only has a new
Shelly wrote:
Im thinking of using the QmailToaster Plus to upgrade my old (read 18
months) Toaster install -
Which version(s)?
# rpm -qa | grep toaster
Im not sure if its been covered, but this will
continue to run the current qmail setup, build the new version in the
background
Pretty
I've tried to upgrade by upgrade.sh, it's very straight forward. The only concern is that you may have to take down your qmail for a while and wait for all packages to be rebuilt.
Take a look about qmail-toaster plus: http://wiki.qmailtoaster.com/index.php/QmailToaster-Plusand
[EMAIL PROTECTED] wrote:
How safe is it to run the upgrade script on a production server. I would
to upgrade to the latest packages but I'm a little nervous. Thanks.
-
QmailToaster hosted by: VR Hosted
I also ran the qtp-newmodel upgrade using qtp-menu on my production server and it worked like a charm.Ryan Gibbons [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote:How safe is it to run the upgrade script on a production server. I wouldto upgrade to the latest packages but I'm a
el: lunes, 13 de noviembre de 2006 17:58
Para: qmailtoaster-list@qmailtoaster.com
Asunto: Re: [qmailtoaster] upgrade script
I also ran the qtp-newmodel upgrade using qtp-menu on my production server
and it worked like a charm.
Ryan Gibbons [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote
el: lunes,
13 de noviembre de 2006 17:58
Para: qmailtoaster-list@qmailtoaster.com
Asunto: Re: [qmailtoaster] upgrade script
I also ran the qtp-newmodel upgrade using qtp-menu on my production server
and it worked like a charm.
Ryan Gibbons [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED
: [qmailtoaster] upgrade script
I also ran the qtp-newmodel upgrade using qtp-menu on my production server
and it worked like a charm.
Ryan Gibbons [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
How safe is it to run the upgrade script on a production
server. I
Asunto: Re: [qmailtoaster] upgrade script
I totally agree, David. That's why I wrote the qtp-newmodel scripts to do
just that!
They do everything except the update ahead of time in the sandbox, so the
production server is not affected. Then at the appropriate moment, the
sysadmin can re-run
I have noted that the restore processing in the script could use some
enhancing. Presently, it simply allows you to restore the configuration
files or bypass restoration.
Bryan, if you selected to do the restore, then this is a bug. If you chose
not to restore, then this is as it should be. Did
Maybe doing in drugs is worth trying, maybe it imporove the carefullness. ;P
Q
On Mon, 13 Nov 2006 18:15:16 +0100, David Sánchez Martín wrote:
Certainy, out alert system, I thinks
BTW i'm not in drugs, just typed uncarefully :-D
De: Francisco Paco Peralta [mailto:[EMAIL PROTECTED] Enviado el: lunes, 13 de noviembre de 2006 17:58 Para: qmailtoaster-list@qmailtoaster.com Asunto: Re: [qmailtoaster] upgrade script I also ran the qtp-newmodel upgrade using qtp-menu on my production server and it worked like a charm.
Harry Zink wrote:
As good a time as any to ask this - I'm about to proceed with an update
of my QMT installation, and running qtp-whatami.sh yields this:
qtp-whatami v0.1.1
DISTRO=CentOS
OSVER=4.4
ARCH=x86_64
BUILD_DIST=cnt40
BUILD_DIR=/usr/src/redhat
This machine's OS is supported, but
On Oct 22, 2006, at 8:38 AM, Eric Shubes wrote:
You too seem to have an older version of the script(s), as they no
longer
have the .sh suffix. You should download the current scripts for
best results.
I downloaded the ones linked at:
As good a time as any to ask this - I'm about to proceed with an
update of my QMT installation, and running qtp-whatami.sh yields this:
qtp-whatami v0.1.1
DISTRO=CentOS
OSVER=4.4
ARCH=x86_64
BUILD_DIST=cnt40
BUILD_DIR=/usr/src/redhat
This machine's OS is supported, but this version/arch has
[EMAIL PROTECTED] wrote:
Greetings,
A quick question: I have a newly built toaster (end of July of this year)
on CentOS 4.x which I'm finally getting ready to deploy.
Before I do so, is it necessary/appropriate to run the upgrade script I
just found on the toaster website, or am I better
On Thu, October 5, 2006 12:33 pm, [EMAIL PROTECTED] wrote:
Greetings,
A quick question: I have a newly built toaster (end of July of this year)
on CentOS 4.x which I'm finally getting ready to deploy.
Before I do so, is it necessary/appropriate to run the upgrade script I
just found on the
fuzzy wrote:
On Thu, October 5, 2006 12:33 pm, [EMAIL PROTECTED] wrote:
Greetings,
A quick question: I have a newly built toaster (end of July of this year)
on CentOS 4.x which I'm finally getting ready to deploy.
Before I do so, is it necessary/appropriate to run the upgrade script I
just
On Thu, 5 Oct 2006, Eric Shubes wrote:
Eric,
Alternatively, you can use the qtp-* scripts at http://qmt.shubes.net to do
the upgrade. They take a bit longer to run because they create a sandbox for
building the binary rpms, however the qmail downtime is minimal. I expect
that this will
[EMAIL PROTECTED] wrote:
On Thu, 5 Oct 2006, Eric Shubes wrote:
Eric,
Alternatively, you can use the qtp-* scripts at http://qmt.shubes.net to do
the upgrade. They take a bit longer to run because they create a sandbox for
building the binary rpms, however the qmail downtime is minimal. I
Ron Jones wrote:
I got exactly the same response within /opt/qmt-sandbox/usr/src/:
/opt/qmt-sandbox/usr/src/qmt/ ?
/opt/qmt-sandbox/usr/src/qmt/caller
Just to let the list know, Ron and I took this off list and the new upgrade
script has been successfully tested on CentOS4 64-bit.
In
Ron Jones wrote:
# ls -l /bin/bash
-rwxr-xr-x 1 root root 772760 Feb 17 2005 /bin/bash
# ls -l /lib/libtermcap.so.2
lrwxrwxrwx 1 root root 19 Sep 29 2005 /lib/libtermcap.so.2 -
libtermcap.so.2.0.8
# ls -l /lib/libdl.so.2
lrwxrwxrwx 1 root root 14 Mar 22 06:00 /lib/libdl.so.2 -
would and I'll see if I can test build for
you.
George Sweetnam.
- Original Message -
From: Eric Shubes [EMAIL PROTECTED]
To: qmailtoaster-list@qmailtoaster.com
Cc: [EMAIL PROTECTED]
Sent: Wednesday, August 23, 2006 3:05 PM
Subject: Re: [qmailtoaster] upgrade script errors - Still no love
George Sweetnam wrote:
Eric,
You should include a link to your website (test installation qmt) in your
sig file. I had some time this afternoon on a fedora5 box and was going to
run it. Repost the link if you would and I'll see if I can test build for
you.
George Sweetnam.
Thanks,
Did you see it the script create /usr/lib64 and /lib64 directories?
Do /opt/qmt-sandbox/usr/lib64 and /opt/qmt-sandbox/lib64 directories exist
I'm guessing not.
Actually they do:
/opt/qmt-sandbox/lib64/
/opt/qmt-sandbox/usr/lib64/
Are both there
What does # uname -m tell you? I've probably got
Ron Jones wrote:
Did you see it the script create /usr/lib64 and /lib64 directories?
Do /opt/qmt-sandbox/usr/lib64 and /opt/qmt-sandbox/lib64 directories exist
I'm guessing not.
Actually they do:
/opt/qmt-sandbox/lib64/
/opt/qmt-sandbox/usr/lib64/
Are both there
What does # uname -m tell
[EMAIL PROTECTED] qmt-sandbox]# ldd bin/bash
libtermcap.so.2 = /lib64/libtermcap.so.2 (0x003aaf70)
libdl.so.2 = /lib64/libdl.so.2 (0x003c9cc0)
libc.so.6 = /lib64/tls/libc.so.6 (0x003c9c90)
/lib64/ld-linux-x86-64.so.2
I used two 'test' scripts when I was testing this problem:
# cat caller
echo about to call
p1=parm1
p2=parm2
p3=parm3
chroot /opt/qmt-sandbox \
/usr/src/qmt/called \
$p1 \
$p2 \
$p3
echo returned from called
# cat called
echo 0=$0 1=$1 2=$2 3=$3
exit
Try creating caller,
Ron Jones wrote:
I used two 'test' scripts when I was testing this problem:
# cat caller
echo about to call
p1=parm1
p2=parm2
p3=parm3
chroot /opt/qmt-sandbox \
/usr/src/qmt/called \
$p1 \
$p2 \
$p3
echo returned from called
# cat called
echo 0=$0 1=$1 2=$2 3=$3
exit
Try
Did you create the 'called' script in the same manner?
Oops.. Lol
No
Ok, what I've just done is gone to /usr/src/qmt;
Cp caller called
Then:
[EMAIL PROTECTED] qmt]# ./caller
About to call
Chroot: cannot run command '/usr/src/qmt/called' : No such file or directory
Returned from called
Ron Jones wrote:
Did you create the 'called' script in the same manner?
Oops.. Lol
No
Ok, what I've just done is gone to /usr/src/qmt;
Cp caller called
'caller' is different than 'called'. 'caller' should be:
# cat /opt/qmt-sandbox/usr/src/qmt/called
echo 0=$0 1=$1 2=$2 3=$3
exit
Then:
[EMAIL PROTECTED] qmt]# ./caller
About to call
Chroot: cannot run command '/usr/src/qmt/called' : No such file or
directory Returned from called 0=./caller 1= 2= 3=
'called' needs to be withing the chroot'd environment, i.e. it needs to be
in /opt/qmt-sandbox/usr/src/qmt. Make
Ron Jones wrote:
Then:
[EMAIL PROTECTED] qmt]# ./caller
About to call
Chroot: cannot run command '/usr/src/qmt/called' : No such file or
directory Returned from called 0=./caller 1= 2= 3=
'called' needs to be withing the chroot'd environment, i.e. it needs to be
in
Eric Shubes wrote:
Ron Jones wrote:
Ok...
[EMAIL PROTECTED] qmt]# chroot /opt/qmt-sandbox
Returned:
chroot: cannot run command '/bin/bash' : No such file or directory
Ron,
That's basically the same error I experienced during testing (I'm not
getting it now, on two separate boxes). I
Eric,
This will fail because your sandbox doesn't copy (link?) the /lib64
and /usr/lib64 directories which contain the 64 bit libs. Your script
is not 64-bit safe yet and will need some work and testing.
Thanks,
Erik
On 8/21/06, Eric Shubes [EMAIL PROTECTED] wrote:
Eric Shubes wrote:
Ron
That would do it all right. ;) I wasn't aware that these directories existed!
It's going to take me a little while to do fix this right. I'll let you know
when it's ready, hopefully by tomorrow.
Thanks, Erik!
P.S. What took you so long to chime in on this? ;)
Erik Espinoza wrote:
Eric,
P.S. What took you so long to chime in on this?
I've been trying to field ones that hadn't been responded too by the
major users such as you and Jake.
I'll try to pay more attention.
Erik
-
QmailToaster hosted by: VR
Erik Espinoza wrote:
P.S. What took you so long to chime in on this?
I've been trying to field ones that hadn't been responded too by the
major users such as you and Jake.
I'll try to pay more attention.
Erik
blushes
I'm just yankin' your chain.
Me a major user? Not compared to you and
Erik Espinoza wrote:
Eric,
This will fail because your sandbox doesn't copy (link?) the /lib64
and /usr/lib64 directories which contain the 64 bit libs. Your script
is not 64-bit safe yet and will need some work and testing.
Thanks,
Erik
On 8/21/06, Eric Shubes [EMAIL PROTECTED] wrote:
Eric
I got exactly the same response within /opt/qmt-sandbox/usr/src/:
/opt/qmt-sandbox/usr/src/qmt/ ?
/opt/qmt-sandbox/usr/src/qmt/caller
-
QmailToaster hosted by: VR Hosted http://www.vr.org
Eric,
This will fail because your sandbox doesn't copy (link?) the /lib64 and
/usr/lib64 directories which contain the 64 bit libs. Your script is not
64-bit safe yet and will need some work and testing.
Thanks,
Erik
Oops :)
Well, I can't write, but I can test.
That would do it all right. ;) I wasn't aware that these directories
existed!
It's going to take me a little while to do fix this right. I'll let you
know when it's ready, hopefully by tomorrow.
If you don't have a 64-bit box to play with, you're welcome to use mine.
Ron
Ok Ron. A 64-bit compatible (I hope) script is available now. Please
download it and give it a try. It shouldn't hurt anything if it doesn't work
(but you do have a backup, right?).
You'll need to recreate the sandbox when you run it. You should see the
/usr/lib64 and /lib64 directories
Ron Jones wrote:
That would do it all right. ;) I wasn't aware that these directories
existed!
It's going to take me a little while to do fix this right. I'll let you
know when it's ready, hopefully by tomorrow.
If you don't have a 64-bit box to play with, you're welcome to use mine.
Ron
Thanks for the offer, Ron. I don't have one, but will keep you in mind
should the need arise. I guess we're using yours anyhow! :)
Well, it's running right now... We'll see ;)
-
QmailToaster hosted by: VR Hosted
Ron Jones wrote:
Thanks for the offer, Ron. I don't have one, but will keep you in mind
should the need arise. I guess we're using yours anyhow! :)
Well, it's running right now... We'll see ;)
Has it started into the compiles yet, or is it still building the sandbox?
--
-Eric 'shubes'
Has it started into the compiles yet, or is it still building the sandbox?
still building the sandbox,
/usr/share
That seems to take a while
-
QmailToaster hosted by: VR Hosted http://www.vr.org
Last step in the sandbox
/usr/var
Now it's REALLY time to go get coffee
-
QmailToaster hosted by: VR Hosted http://www.vr.org
-
To unsubscribe, e-mail:
Has it started into the compiles yet, or is it still building the sandbox?
It errored out again...
chroot: cannot run command '/usr/src/qmt/qmt-build-rpms.sh' : No such file
or directory
Build failed, Exiting.
Well...
Is there a log file somewhere that may give a more specific reason behind
Ron Jones wrote:
Has it started into the compiles yet, or is it still building the sandbox?
It errored out again...
chroot: cannot run command '/usr/src/qmt/qmt-build-rpms.sh' : No such file
or directory
Build failed, Exiting.
Well...
Is there a log file somewhere that may give a more
Ron Jones wrote:
That still doesn't explain how /usr/src got wiped out though. You didn't run
it with SANDROOT=/usr/src did you?
Well... I don't believe so.
Also:
During the last 40 minutes, I've been running a fresh instance of the
upgrade script, it failed again.
Just to make sure
Ron Jones wrote:
I don't have reason to believe that the No such file problem is fixed,
but I'd like you to do this (again):
.) delete the scripts you have
.) reboot the server if at all feasible. /etc/mtab might be a bit wacky
with the abnormal exits, and I just want to eliminate that from a
This error drove me nuts one time testing. I can't yet remember the
solution. Unfortunately I didn't ask the question on my local LUG or I'd
have posted the answer. I really need to make notes sometimes.
Yes, I know the feeling, I've got to document more than I do
Ok, let's see if we can nail
Ron Jones wrote:
This error drove me nuts one time testing. I can't yet remember the
solution. Unfortunately I didn't ask the question on my local LUG or I'd
have posted the answer. I really need to make notes sometimes.
Yes, I know the feeling, I've got to document more than I do
Ok, let's
Oops. I forgot the format. Try
# chroot /opt/qmt-sandbox
That should either give you a shell prompt in the named directory. If it
tells you it can't find shell, that the same error as we're seeing in the
script. We'll take it from there.
Ok...
[EMAIL PROTECTED] qmt]# chroot /opt/qmt-sandbox
Ron Jones wrote:
Ok...
[EMAIL PROTECTED] qmt]# chroot /opt/qmt-sandbox
Returned:
chroot: cannot run command '/bin/bash' : No such file or directory
Ron,
That's basically the same error I experienced during testing (I'm not
getting it now, on two separate boxes). I expected such. At least
Ron Jones wrote:
Oops. I forgot the format. Try
# chroot /opt/qmt-sandbox
That should either give you a shell prompt in the named directory. If it
tells you it can't find shell, that the same error as we're seeing in the
script. We'll take it from there.
Ok...
[EMAIL PROTECTED] qmt]# chroot
I just found an easier way to check this out. You should be able to just #
cd /opt/qmt-sandbox # ldd bin/bash
libtermcap.so.2 = /lib/libtermcap.so.2 (0x002bf000)
libdl.so.2 = /lib/libdl.so.2 (0x00294000)
libc.so.6 = /lib/tls/libc.so.6 (0x00168000)
/lib/ld-linux.so.2 (0x0014f000)
What do you get?
Ron Jones wrote:
I just found an easier way to check this out. You should be able to just #
cd /opt/qmt-sandbox # ldd bin/bash
libtermcap.so.2 = /lib/libtermcap.so.2 (0x002bf000)
libdl.so.2 = /lib/libdl.so.2 (0x00294000)
libc.so.6 = /lib/tls/libc.so.6 (0x00168000)
/lib/ld-linux.so.2 (0x0014f000)
Ron Jones wrote:
I just found an easier way to check this out. You should be able to just #
cd /opt/qmt-sandbox # ldd bin/bash
libtermcap.so.2 = /lib/libtermcap.so.2 (0x002bf000)
libdl.so.2 = /lib/libdl.so.2 (0x00294000)
libc.so.6 = /lib/tls/libc.so.6 (0x00168000)
/lib/ld-linux.so.2 (0x0014f000)
Ron Jones wrote:
I'm running CentOS 4.3, and tried running the upgrade script on the wiki
(not on a production box, just my home email server) :
qmt-newmodel.sh and qmt-build-rpms.sh
It seemed to go well through the creation of the sandbox. I got the
Sandbox has been built successfully!
Eric Shubes wrote:
Ron Jones wrote:
I'm running CentOS 4.3, and tried running the upgrade script on the
wiki (not on a production box, just my home email server) :
qmt-newmodel.sh and qmt-build-rpms.sh
It seemed to go well through the creation of the sandbox. I got the
Sandbox has been
I'm guessing that ownership of qmt-bulid-rpms.sh isn't root. Oops, my bad.
I gather you obtained the scripts under a different user id.
No, I started with: su -
Then did wget and sh all as root
# ls -l /opt/qmt-sandbox/usr/src/qmt/qmt-build-rpms.sh
to verify that it's not owned by root, then #
P.S. I've changed permissions of both scripts to 755 so this shouldn't
happen again, provided that wget preserves permission settings.
I just changed the permissions to 755 and it's running as we 'speak,' so
I'll keep you posted.
An interesting aside...
When it didn't work the first time, I
Ron Jones wrote:
I'm guessing that ownership of qmt-bulid-rpms.sh isn't root. Oops, my bad.
I gather you obtained the scripts under a different user id.
No, I started with: su -
Then did wget and sh all as root
# ls -l /opt/qmt-sandbox/usr/src/qmt/qmt-build-rpms.sh
to verify that it's not
Ron Jones wrote:
P.S. I've changed permissions of both scripts to 755 so this shouldn't
happen again, provided that wget preserves permission settings.
I just changed the permissions to 755 and it's running as we 'speak,' so
I'll keep you posted.
An interesting aside...
When it didn't work
Ron Jones wrote:
This is disturbing to me. You didn't point the SANDROOT variable to
/usr/src, did you? That would be not a good thing. I should probably mention
in the wiki something about making it a *new* directory that doesn't already
exist.
I don't see how the script otherwise could wipe
Ron Jones wrote:
That still doesn't explain how /usr/src got wiped out though. You didn't run
it with SANDROOT=/usr/src did you?
Well... I don't believe so.
Also:
During the last 40 minutes, I've been running a fresh instance of the
upgrade script, it failed again.
Just to make sure
Ron Jones wrote:
This is disturbing to me. You didn't point the SANDROOT variable to
/usr/src, did you? That would be not a good thing. I should probably mention
in the wiki something about making it a *new* directory that doesn't already
exist.
I don't see how the script otherwise could wipe
77 matches
Mail list logo
