On 6/19/12 12:26 PM, Eric Shubert wrote:
On 06/19/2012 11:59 AM, Casey James Price wrote:
On 6/19/12 8:14 AM, Eric Shubert wrote:
On 06/19/2012 04:26 AM, Bharath Chari wrote:
On Tuesday 19 June 2012 09:45 AM, Casey Price wrote:
On 6/18/12 8:13 AM, Cecil Yother, Jr. wrote:
On 06/18/2012 07:58 AM, Eric Shubert wrote:
On 06/17/2012 11:33 PM, Casey Price wrote:
Hi all,
Just noticed a problem on one of my virtualized xen QMT boxes when
running qtp-ami-up2date
Received the following error:
/usr/sbin/qtp-config: line 168: 1.el5: syntax error: invalid
arithmetic
operator (error token is ".el5")
I'm running CentOS 5.8 i386. Any ideas?
Thanks,
--
Casey Price
Leave it to CJ to break something. ;)
Please post:
# rpm -q | grep toaster | sort
That part of the code is comparing the installed version of a
package to the version listed as current. It's a little tricky to
do, at least in a shell script. Given that it's choking on "1.el5",
where it appears to need simply "1", I'm guessing that a package
that is installed on your system which has "el5" in it at the end,
where the stock QMT packages do not. The result of the command
above
may show us this.
That definitely makes sense...
Here is the output (BTW, *rpm -q |grep toaster |sort *throws back the
following error: *rpmq: no arguments given for query*)
However, running this seems to do the trick: *rpm -qa |grep toaster
|sort
*
autorespond-toaster-2.0.4-1.3.6
clamav-toaster-0.97.4-1.4.0
control-panel-toaster-0.5-1.3.7
courier-authlib-toaster-0.59.2-1.3.10
courier-imap-toaster-4.1.2-1.3.10
daemontools-toaster-0.76-1.3.6
isoqlog-toaster-2.1-1.3.7
libdomainkeys-toaster-0.68-1.3.6
libsrs2-toaster-1.0.18-1.3.6
maildrop-toaster-2.0.3-1.3.8
maildrop-toaster-devel-2.0.3-1.3.8
qmailmrtg-toaster-4.2-1.3.6
qmail-pop3d-toaster-1.03-1.3.22
qmail-toaster-1.03-1.3.22
qmailtoaster-plus-0.3.2-1.4.18
qmailtoaster-plus.repo-0.2-2
ripmime-toaster-1.4.0.6-1.3.6
simscan-toaster-1.4.0-1.3.8
spamassassin-toaster-3.2.5-1.3.17
ucspi-tcp-toaster-0.88-1.3.9
vpopmail-toaster-5.4.17-1.3.7
As far as I can recall, no - I haven't built any customized
version of
any of the packages (its possible, but I'm pretty darn sure
everything
is stock, as I just recently built this host.
rpmforge packages use .el5 . Did you update something from there? Just
guessing here.
Bharath
What about
# rpm -qa | grep djbdns
?
Ahh, looks like we do have something here... djbdns-1.05-1.el5
So, what do I do now.
Casey James Price
Smile Global Technical Support
Submit or check trouble tickets http://billing.smileglobal.com
www.smileglobal.com <http://www.smileglobal.com>
Follow us on Twitter <https://twitter.com/#%21/SmileInternet>
Find us on Facebook <https://www.facebook.com/smileglobal>
I've modified qtp-get-pkg-list to skip djbdns. That's not a -toaster
package, and we never update it. We'll keep it around for posterity,
but it won't be the preferred dns resolver. The caching-nameserver
(bind9) and pdns-recursor are both part of the centos base repos. Pick
either one (my preference is pdns-recursor).
The simplest way to get the fix for qtp-get-pkg-list until I cut a new
QTP release will be to simply edit the file manually. Change line 56
from this:
"$pkg" | "zlib" )
to this:
"$pkg" | "zlib" | "djbdns" )
Let us know if that fixes it up.
Just to make sure I've got this right, you are saying to change line 56
in qtp-get-pkg-list to what you have listed above, right? I tried this
and then ran qtp-ami-up2date again and am still getting an error.
Its not a big deal right now, as I built the RPM for the latest version
of clamav from the spec file and got it installed, but this is
definitely something I'd like to fix moving forward. We are using dbjdns
as our primary backbone on our DNS servers as its what was in-place when
I took over the company, its simple, and its been working well. It just
so happens that this particular VPS is setup with the intention of being
an offsite DNS server as well as MX server via QMT (one of the providers
I've been using is Thrust:VPS aka Damn:VPS...my gateway3 box is OpenVZ
and has had its share of problems...for some reason these guys have a
very hard time keeping the VPS running all week long and I'm constantly
finding myself contacting them to reboot it as their SolusVM interface
doesn't actually work - however...I setup a xen-based VPS with them over
in the UK a few months back and haven't hadf any issues with it at all,
so I figured I would make this a backup MX server and also utilize the
VPS to take the role of my current d.ns.smileglobal.com DNS server)
So, needless to say, I'm hoping to stick with djbdns for a bit at least
on some of these boxes. Q2 and my "vcluster1" box (yes, the name does
in-fact say it all...its built following the guidelines from Jake's QMT
ISP Array video series) both run QMT and bind as the resolver if I
remember correctly, but my old Solaris boxes and their latest
re-incarnations on the Linux side of things are using tinydns to provide
DNS for the customers. Anyways, sorry to ramble on...these last two
paragraphs or so don't really have much relevance in this whole issue,
but I just wanted to explain where I was coming from.
Thanks,
Casey James Price
Smile Global Technical Support
Submit or check trouble tickets http://billing.smileglobal.com
www.smileglobal.com <http://www.smileglobal.com>
Follow us on Twitter <https://twitter.com/#%21/SmileInternet>
Find us on Facebook <https://www.facebook.com/smileglobal>