Greetings all, newbie to CentOS here. Also newbie to 64 bit installs.
Package Manager problem:
I found a yumex, which is not part of the 64 bit install, but it wants a way older version of python-2.4 whereas we have 2.6.6-something after the post install upgrade.
1st Question: Is there anything that can be done about this? Or is there something better, like a 64 bit synaptic to replace yumex?
Mail problem:
I've been using a fetchmail -> procmail system here for years to unload kmail from its mail pulling duties, making it many times easier to use.
Adjuncts to that are spamassassin, clamav, and mailfilter
There appears not to be any 64 bit builds of clamav and mailfilter.
I do have the src for mailfilter, however it refuses to build on x86-64, issuing this error: ================== Making all in src gmake[2]: Entering directory `/usr/src/mailfilter-0.8.2/src' g++ -DHAVE_CONFIG_H -I. -I.. -I/usr/local/include -I. -I../include -I.. - DLOCALEDIR="/usr/local/share/locale" -I../intl -I.. -I../include -I. - Wall -g -O2 -MT header.o -MD -MP -MF .deps/header.Tpo -c -o header.o header.cc header.cc: In member function ‘int Header::rfc822_valid_msgid(const char*)’: header.cc:77: error: invalid conversion from ‘const char*’ to ‘char*’ gmake[2]: *** [header.o] Error 1 gmake[2]: Leaving directory `/usr/src/mailfilter-0.8.2/src' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/src/mailfilter-0.8.2' gmake: *** [all] Error 2 ===================
Lines 77-78 in that file: if (!(dom = strrchr (msgid, '@'))) return -1;
Obviously strrchr() tries to convert the header spec here from line 35:
int Header :: rfc822_valid_msgid (const char* msgid)
into a plain char. Boom on a 64 bit machine.
2nd Question:
How best to fix that? I know enough C to be dangerous, but somewhere between .0000zip and absolutely nothing about c++.
There are other mail related problems, like a missing inotifywait and its library, but moving the 32 bit versions into what appeared to be the correct locations, and that seems to work 99% well.
Suffice to say mail is moving, but the noise filters aren't working.
Thanks to anyone who can help here.
Cheers, Gene
On Jun 20, 2012, at 1:59 PM, Gene Heskett wrote:
I found a yumex, which is not part of the 64 bit install, but it wants a way older version of python-2.4 whereas we have 2.6.6-something after the post install upgrade.
1st Question: Is there anything that can be done about this? Or is there something better, like a 64 bit synaptic to replace yumex?
You may be unfamiliar with CentOS in that many tools you might find "standard" on regular distros, aren't part of the upstream package list for "Enterprise" Linux. As delivered from upstream, it's a fairly "stripped" distro.
Yumex is not packaged by upstream, so it's not part of CentOS proper.
However, there are repositories that build packages to run under CentOS which aren't part of upstream or CentOS, such as EPEL: http://fedoraproject.org/wiki/EPEL
yumex in particular, if you're partial to it, is available in various flavors, all ready to install.
Mail problem:
I've been using a fetchmail -> procmail system here for years to unload kmail from its mail pulling duties, making it many times easier to use.
Adjuncts to that are spamassassin, clamav, and mailfilter
There appears not to be any 64 bit builds of clamav and mailfilter.
Many 32-bit packages run just fine on 64-bit CentOS via the use of 32-bit libraries.
A quick look through a machine that has both stock CentOS software repositories and EPEL enabled shows that there are packages for all of the above, except mailfilter. Mailfilter appears to be somewhat Debian-centric and the Debian-distro-derivatives all seem to have updated packages. I've never used it, even though I'm a fan of both "camps" for various things.
Looking it over, it looks like it utilizes POP to go take a look at mail and dump spam prior to the POP transfer of whatever is left over? Honestly, most folks have moved on to IMAP, long ago... IMHO. YMMV.
The advent of large data pipes, even in residential service in most areas, and effective local filtering probably means that mailfilter is marginalized non-mainstream software, at best, these days.
Doing some quick Googling, mailfilter doesn't seem very popular at all with the RedHat-derivative camp. The only distro that seems to have ever had it pre-packaged is Mandriva. You might look at whatever changes they made to make their x86_64 package. It's not in Fedora either...
https://admin.fedoraproject.org/pkgdb/acls/list/m*?_csrf_token=1320052a8a44a...
Nate
On Wednesday 20 June 2012 17:08:11 Nate Duehr did opine:
On Jun 20, 2012, at 1:59 PM, Gene Heskett wrote:
I found a yumex, which is not part of the 64 bit install, but it wants a way older version of python-2.4 whereas we have 2.6.6-something after the post install upgrade.
1st Question: Is there anything that can be done about this? Or is there something better, like a 64 bit synaptic to replace yumex?
You may be unfamiliar with CentOS in that many tools you might find "standard" on regular distros, aren't part of the upstream package list for "Enterprise" Linux. As delivered from upstream, it's a fairly "stripped" distro.
Yumex is not packaged by upstream, so it's not part of CentOS proper.
However, there are repositories that build packages to run under CentOS which aren't part of upstream or CentOS, such as EPEL: http://fedoraproject.org/wiki/EPEL
yumex in particular, if you're partial to it, is available in various flavors, all ready to install.
I did find one, needed pexpect and python-kitchen, but its favorite way of quitting is by a crash when fiddling with the repo editor.
As for partiality, no way, synaptic, adapted for rpms is by far the best package manager I've used in the last 5 years since I bailed on fedora at about 6 or so.
Mail problem:
I've been using a fetchmail -> procmail system here for years to unload kmail from its mail pulling duties, making it many times easier to use.
Adjuncts to that are spamassassin, clamav, and mailfilter
There appears not to be any 64 bit builds of clamav and mailfilter.
Many 32-bit packages run just fine on 64-bit CentOS via the use of 32-bit libraries.
I just pulled the clamav stuff, not terribly complete unless the utils are part of the main package, but have not attempted an rpm -ivh on that kit yet. I got the huge majority of the stuff with FF, at http://choonrpms.mirror.choon.net/centos/6.2/choonrpms/x86_64/ which I found via a google search.
A quick look through a machine that has both stock CentOS software repositories and EPEL enabled shows that there are packages for all of the above, except mailfilter. Mailfilter appears to be somewhat Debian-centric and the Debian-distro-derivatives all seem to have updated packages. I've never used it, even though I'm a fan of both "camps" for various things.
So am I, I have 3 other machines here, all running Ubuntu-10.04 LTS, with two of them essentially frozen in time re kernel versions because that are the cnc heart of some of my machine tools.
Looking it over, it looks like it utilizes POP to go take a look at mail and dump spam prior to the POP transfer of whatever is left over? Honestly, most folks have moved on to IMAP, long ago... IMHO. YMMV.
The advent of large data pipes, even in residential service in most areas, and effective local filtering probably means that mailfilter is marginalized non-mainstream software, at best, these days.
I'm getting close to that in N. Central WV, phone and internet are on the local cable, getting about 385k/sec dl speeds on average. But I have kept my own email corpus here since 1998, over 7Gb of it now, and old, probably bad habits are hard to break. Old being relative of course since I'm only slightly younger than dirt at 77. Retired (almost, I take a small plane ride tomorrow to go look at a transmitter that is off the air) from the local CBS affiliate as the CE from 1984.9 to 2002.6.
Doing some quick Googling, mailfilter doesn't seem very popular at all with the RedHat-derivative camp. The only distro that seems to have ever had it pre-packaged is Mandriva. You might look at whatever changes they made to make their x86_64 package. It's not in Fedora either...
Thanks, I'll see if I can google that when I get back from the trip & get over my aches & pains from crawling around in that elderly Harris 50kw transmitter.
https://admin.fedoraproject.org/pkgdb/acls/list/m*?_csrf_token=1320052a8 a44a38e84b472e63f9cba4db006ea38
Nate
Thanks Nate, I appreciate the speedy response!
Cheers, Gene
On Wed, Jun 20, 2012 at 4:27 PM, Gene Heskett gheskett@wdtv.com wrote:
I'm getting close to that in N. Central WV, phone and internet are on the local cable, getting about 385k/sec dl speeds on average. But I have kept my own email corpus here since 1998, over 7Gb of it now, and old, probably bad habits are hard to break.
I think google/gmail gives you 10 gigs for free these days. Or at the cost of ignoring the ads on the right side if you use the web interface, but you can use imap if you want. Before they offered imap I used to use fetchmail to pull to my own server but I don't bother anymore.
On Wednesday, June 20, 2012, Les Mikesell wrote:
I think google/gmail gives you 10 gigs for free these days. Or at the cost of ignoring the ads on the right side if you use the web interface, but you can use imap if you want. Before they offered imap I used to use fetchmail to pull to my own server but I don't bother anymore.
Using Google Apps you can even have them host your own domain. Life's too short to spend time running your own mail server.
Gé
On Jun 20, 2012, at 3:27 PM, Gene Heskett wrote:
As for partiality, no way, synaptic, adapted for rpms is by far the best package manager I've used in the last 5 years since I bailed on fedora at about 6 or so.
Understand that sentiment, Gene. I like aptitude myself for Debian-based systems, but everyone has a favorite.
It sounds like you have much of your repo problem for RPM sources for the tools you want understood now. I would caution that some repos out there are set up by individuals who are interested in fixing something, they make a few packages, and then they disappear when they lose interest.
I suggested EPEL because it's a large project, based off of an even larger one (Fedora) and there's probably not going to be any major disruptions in it as far as interested-parties goes, so security and version updates of most packages in it should keep flowing unless upstream sources abandon them.
I just pulled the clamav stuff, not terribly complete unless the utils are part of the main package, but have not attempted an rpm -ivh on that kit yet. I got the huge majority of the stuff with FF, at http://choonrpms.mirror.choon.net/centos/6.2/choonrpms/x86_64/ which I found via a google search.
Highly recommend adding reputable repos to your local system and then using yum search [packagename] or similar... I haven't seen the name choonrpms before, but I'd kinda want to know who they are before installing their packages. Just a thought. Take or leave. (Someone who knows who they are, may be chuckling at that... I don't know... I haven't researched it.)
I'm getting close to that in N. Central WV, phone and internet are on the local cable, getting about 385k/sec dl speeds on average. But I have kept my own email corpus here since 1998, over 7Gb of it now, and old, probably bad habits are hard to break. Old being relative of course since I'm only slightly younger than dirt at 77. Retired (almost, I take a small plane ride tomorrow to go look at a transmitter that is off the air) from the local CBS affiliate as the CE from 1984.9 to 2002.6.
I will add my vote that even though running ones own mail server is a fun challenge, at some point in the past I decided to leave it to younger pros who get paid to wrangle with spammers and what-not, and now only run mail servers I'm paid to deal with. (GRIN!)
I migrated old mail that I thought I couldn't live without to the IMAP account and said goodbye to the time-suck that a modern mail server has become. (I still operate mail servers for my employer, but at home... it's nice to just forget about it and read my mail. GRIN...)
Neat to run into another RF "geek". Never made my living at it, but I maintain some Amateur Radio FM repeaters and some Public Safety FM and P-25 systems. Nothing high power, broadcast or TV, but as things are generally co-located on mountains... have seen many broadcast systems up close, and had the "5 cent tour" from the Station Engineers in the area.
Be careful with that high-power stuff... but you know that already. No tower climbing at 77... let one of us young whippersnappers do that silly stuff. I'm about half your age, and I still don't really like it. Just a necessary evil in volunteer organizations... strap on the safety gear, and get going.
You mentioned a small plane... I do small planes for fun these days, and I'd much rather be doing that, than climbing a tower. (GRIN!)
Thanks, I'll see if I can google that when I get back from the trip & get over my aches & pains from crawling around in that elderly Harris 50kw transmitter.
CBS does love their Harris stuff, eh? I got to see the new solid state beast out here in Denver in person... 1KW modules, pop one out, pop one in... touch screen to gracefully fail one if you want to pull it... pretty amazing stuff. Paul (the Engineer here) really enjoys his broadcast radio and other radio toys. That was one of the "five cent tours", seeing his new setup in a shared building with various other DTV systems co-located. Newest site I've ever been in. Nice setup. Always interesting to see waveguide bigger than most sewer pipes and the associated filters. Looks like an old steamworks for a steamship, but all "filled" with RF instead of water vapor...
Enjoy your "retirement"... and 73 if you're a Ham... WY0X here.
Nate
p.s. Apologies to the list for the personal notes and digressing a bit... I don't think I know Gene well enough to send him private messages. All the best.
On Saturday 23 June 2012 15:12:58 Nate Duehr did opine:
On Jun 20, 2012, at 3:27 PM, Gene Heskett wrote:
As for partiality, no way, synaptic, adapted for rpms is by far the best package manager I've used in the last 5 years since I bailed on fedora at about 6 or so.
Understand that sentiment, Gene. I like aptitude myself for Debian-based systems, but everyone has a favorite.
It sounds like you have much of your repo problem for RPM sources for the tools you want understood now. I would caution that some repos out there are set up by individuals who are interested in fixing something, they make a few packages, and then they disappear when they lose interest.
I suggested EPEL because it's a large project, based off of an even larger one (Fedora) and there's probably not going to be any major disruptions in it as far as interested-parties goes, so security and version updates of most packages in it should keep flowing unless upstream sources abandon them.
I believe EPEL is enabled, but will check as soon as I've recovered from 4k air miles in a Cessna 414, and 2 days crawling all over an old Harris 50KW tv transmitter that wasn't transmitting.
I just pulled the clamav stuff, not terribly complete unless the utils are part of the main package, but have not attempted an rpm -ivh on that kit yet. I got the huge majority of the stuff with FF, at http://choonrpms.mirror.choon.net/centos/6.2/choonrpms/x86_64/ which I found via a google search.
Highly recommend adding reputable repos to your local system and then using yum search [packagename] or similar... I haven't seen the name choonrpms before, but I'd kinda want to know who they are before installing their packages. Just a thought. Take or leave. (Someone who knows who they are, may be chuckling at that... I don't know... I haven't researched it.)
I'm getting close to that in N. Central WV, phone and internet are on the local cable, getting about 385k/sec dl speeds on average. But I have kept my own email corpus here since 1998, over 7Gb of it now, and old, probably bad habits are hard to break. Old being relative of course since I'm only slightly younger than dirt at 77. Retired (almost, I take a small plane ride tomorrow to go look at a transmitter that is off the air) from the local CBS affiliate as the CE from 1984.9 to 2002.6.
I will add my vote that even though running ones own mail server is a fun challenge, at some point in the past I decided to leave it to younger pros who get paid to wrangle with spammers and what-not, and now only run mail servers I'm paid to deal with. (GRIN!)
I migrated old mail that I thought I couldn't live without to the IMAP account and said goodbye to the time-suck that a modern mail server has become. (I still operate mail servers for my employer, but at home... it's nice to just forget about it and read my mail. GRIN...)
Yeah boy, right as rain.
Neat to run into another RF "geek". Never made my living at it, but I maintain some Amateur Radio FM repeaters and some Public Safety FM and P-25 systems. Nothing high power, broadcast or TV, but as things are generally co-located on mountains... have seen many broadcast systems up close, and had the "5 cent tour" from the Station Engineers in the area.
I used to charge 50 cents. I never got paid either...
Be careful with that high-power stuff... but you know that already. No tower climbing at 77... let one of us young whippersnappers do that silly stuff. I'm about half your age, and I still don't really like it. Just a necessary evil in volunteer organizations... strap on the safety gear, and get going.
And make sure your safety gear is up to code these days. My old linemans belt would get me a police escort off the site today, but I've been several hundred feet up in a 50-75 mph wind in it. I felt safe enough cuz I had no intentions of doing anything more stupid that tying myself down, and sticking out an arm to catch 330' of 3.125" rigid coax a tower crew from a major name had last worked on, and only put the line mounts cap bolts back in finger tight. I wanted the owner to sue the bsrtds, but had to settle for making that outfit personna-non-grata for the rest of my term as the CE there. 330' twice, it was a 2 line phased setup. I had yelled at the monkey who was doing the tower lites & charging me too much, he came up, wasted a pint of black jack for courage before he started up. The wind was beginning to settle, but by the time he got to me at 280' feet, he was a white as a sheet and froze hisself to the ladder about 4 feet below me. So I had to quit, nearly out of the bolts I had picked up off the ground anyway, and concentrated on getting him back down without being forced to break some fingers.
Now, get this, I am the one afraid of heights! I guess everything can be measured in degrees.
You mentioned a small plane... I do small planes for fun these days, and I'd much rather be doing that, than climbing a tower. (GRIN!)
Small is relative, a Cessna 414 with all the dashboard toys, including a radar we had to use going up when we found that after they'd put a pair of brand new extra power engines in it last winter, we only had deicers on the left wing. So we had to nose up and jump over it, letting the radar steer us for a while. Those fresh engines never broke a sweat. Sweet even. :)
Thanks, I'll see if I can google that when I get back from the trip & get over my aches & pains from crawling around in that elderly Harris 50kw transmitter.
CBS does love their Harris stuff, eh?
Nah, CBS except for an earth station package we bought in '88, never forced us to buy any particular brand. We aren't a CBS O&O, we're an affiliate.
I got to see the new solid state beast out here in Denver in person... 1KW modules, pop one out, pop one in... touch screen to gracefully fail one if you want to pull it... pretty amazing stuff. Paul (the Engineer here) really enjoys his broadcast radio and other radio toys. That was one of the "five cent tours", seeing his new setup in a shared building with various other DTV systems co-located. Newest site I've ever been in. Nice setup. Always interesting to see waveguide bigger than most sewer pipes and the associated filters. Looks like an old steamworks for a steamship, but all "filled" with RF instead of water vapor...
Yup, except that here in the hills, we all pressured the commish to keep our old VHF stuff, but generally, there's not many of those left now. The NRAQZ boundary is about the south city limits here, and UHF stuff inside that zone is quite verboten. The commish when they made the initial channel assignments didn't consider that, & gave the lot of us channels in the 50 & up range. On the #58 they gave us, our power output limit would have been 4.78 _watts_. Hello?
Enjoy your "retirement"... and 73 if you're a Ham... WY0X here.
Never made it past cow barn radio. I was one of the sneakier outlaws, making about 70 watts pip (sideband only, dead legal on ancient mary) that sounded like your living room hifi. But I sold that radio 25 years ago. If I could find it again, I'd buy it back, it would by now be a true collectors item, like an original apple.
A HiGain 623, turned into a 640. Front end noise figure was about 2.1 db when I got done with that, and it was a frequency std when the FT dial was straight up. Golden Eagle lollipop, serial #1772. This was in '76 and I was looking for serial number 1776, but 1772 was as close as I could get.
Last I knew it was someplace around Ashland KY.
Nate
p.s. Apologies to the list for the personal notes and digressing a bit... I don't think I know Gene well enough to send him private messages. All the best.
I'll second that, PM's are fine too.
Cheers, Gene
Hello Gene,
On Wed, 2012-06-20 at 15:59 -0400, Gene Heskett wrote:
header.cc:77: error: invalid conversion from ‘const char*’ to ‘char*’
Lines 77-78 in that file: if (!(dom = strrchr (msgid, '@'))) return -1;
Obviously strrchr() tries to convert the header spec here from line 35:
int Header :: rfc822_valid_msgid (const char* msgid)
into a plain char. Boom on a 64 bit machine.
A char is always 8 bit regardless of the architecture. The issue is a const char* being converted to a char*. Try declaring dom as const char* dom and see if that helps. (Note that this makes the content of the pointer constant, not the pointer itself.)
Regards, Leonard.
Leonard den Ottolander wrote:
Hello Gene,
On Wed, 2012-06-20 at 15:59 -0400, Gene Heskett wrote:
header.cc:77: error: invalid conversion from ‘const char*’ to ‘char*’
Lines 77-78 in that file: if (!(dom = strrchr (msgid, '@'))) return -1;
Obviously strrchr() tries to convert the header spec here from line 35:
int Header :: rfc822_valid_msgid (const char* msgid)
into a plain char. Boom on a 64 bit machine.
A char is always 8 bit regardless of the architecture. The issue is a const char* being converted to a char*. Try declaring dom as const char* dom and see if that helps. (Note that this makes the content of the pointer constant, not the pointer itself.)
Or just if (!(strrchr ( msgid, '@' ))) { return -1; }
mark
-
Gene Heskett -
Gé Weijers -
Leonard den Ottolander -
Les Mikesell -
m.roth＠5-cent.us -
Nate Duehr