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>

Reply via email to