Discuss

discuss@lists.centos.org

34758 discussions

Several files's checksum change without reason
by kadafax 14 Aug '06

14 Aug '06

Hi list, I'm a bit worried here. On a server, Centos 4.3 fully-patched SELinux activated, Osiris (a decentralized scanner for files changes on distant servers) signaled me several changes on files who were not (at first sight) affected by a recent update (the list is below). Is there a logic explanation for those changes to happen ? The "rpm -Va" command does not output md5sum change for those files. compare time: Sat Aug 12 05:35:14 2006 host: server scan config: server (abcdefg) log file: no log file generated, see system log. base database: 56 compare database: 57 [211][server][cmp][/usr/bin][mtime][Sun Aug 6 04:02:20 2006][Sat Aug 12 04:02:22 2006] [213][server][cmp][/usr/bin][ctime][Sun Aug 6 04:02:20 2006][Sat Aug 12 04:02:22 2006] [204][server][cmp][/usr/bin/afs5log][checksum][b838bb6106250fdfd95ae8a7dc7fa95b8f762df4][a4c817dd8ca12449dc1a8bdf7f972c19aa3ffd7b] [206][server][cmp][/usr/bin/afs5log][inode][22423][22422] [213][server][cmp][/usr/bin/afs5log][ctime][Thu Jun 29 21:43:54 2006][Sat Aug 12 04:02:22 2006] [204][server][cmp][/usr/bin/dig][checksum][9d34eb65d61c9f43efc9b6141f727e7fdbb618bf][69d94a240e415b5f22a220fe71dcf865a9a5608c] [206][server][cmp][/usr/bin/dig][inode][25755][25759] [213][server][cmp][/usr/bin/dig][ctime][Thu Jun 29 21:43:48 2006][Sat Aug 12 04:02:21 2006] [204][server][cmp][/usr/bin/elinks][checksum][a62ab203cc0126aa846419ca25e2e2a6524ab58d][a66553759b6392f20b4f4c61d798585636feea9e] [206][server][cmp][/usr/bin/elinks][inode][26239][25433] [213][server][cmp][/usr/bin/elinks][ctime][Thu Jul 27 04:02:16 2006][Sat Aug 12 04:02:22 2006] [204][server][cmp][/usr/bin/host][checksum][f6e94925f133d1a9fe088da757ec60b493800adc][c47534726541474f7a1e1b7d23ec41ed44169118] [206][server][cmp][/usr/bin/host][inode][25133][22958] [213][server][cmp][/usr/bin/host][ctime][Thu Jun 29 21:43:51 2006][Sat Aug 12 04:02:21 2006] [204][server][cmp][/usr/bin/ipmi_ui][checksum][e106a461a907d0dec9f622919ddaed1a84552063][1bb99621c20d3e66f362a355d8d8e09340f748d6] [206][server][cmp][/usr/bin/ipmi_ui][inode][25973][21341] [213][server][cmp][/usr/bin/ipmi_ui][ctime][Thu Jun 29 21:43:53 2006][Sat Aug 12 04:02:22 2006] [204][server][cmp][/usr/bin/ipmish][checksum][f4f38f1f45f83d057b32deb2dbae9940f9d9dcc0][6e13d56f5457213de8302e08c311badcd49b1e46] [206][server][cmp][/usr/bin/ipmish][inode][25042][25755] [213][server][cmp][/usr/bin/ipmish][ctime][Thu Jun 29 21:43:50 2006][Sat Aug 12 04:02:21 2006] [204][server][cmp][/usr/bin/nslookup][checksum][7f7087ace44e1d14e984cd367df3b794cc1859a3][655c9d0f1328aa07f45a061825989809ae5b9885] [206][server][cmp][/usr/bin/nslookup][inode][25595][25317] [213][server][cmp][/usr/bin/nslookup][ctime][Thu Jun 29 21:43:51 2006][Sat Aug 12 04:02:21 2006] [204][server][cmp][/usr/bin/nsupdate][checksum][721695ed63aed8b55d6978b1384a0250d26d4d15][cac7585a8520d619d1a507b160e7a35651db3563] [206][server][cmp][/usr/bin/nsupdate][inode][21341][25780] [213][server][cmp][/usr/bin/nsupdate][ctime][Thu Jun 29 21:43:53 2006][Sat Aug 12 04:02:22 2006] [204][server][cmp][/usr/bin/openssl][checksum][c728d401456ee2003a329eb74e1ea3f008ddcf17][ddc4e323567fac0696dd9aeacea7402869837ff7] [206][server][cmp][/usr/bin/openssl][inode][22379][22423] [213][server][cmp][/usr/bin/openssl][ctime][Thu Jun 29 21:43:54 2006][Sat Aug 12 04:02:22 2006] [211][server][cmp][/usr/sbin][mtime][Fri Jul 28 12:45:00 2006][Sat Aug 12 04:02:23 2006] [213][server][cmp][/usr/sbin][ctime][Fri Jul 28 12:45:00 2006][Sat Aug 12 04:02:23 2006] [204][server][cmp][/usr/sbin/postalias][checksum][f338a0c58cfe235db579d20bea4326fab24f8cb3][c95b319b6cf1427f6c4bcce2c73d6a616b2df0c9] [206][server][cmp][/usr/sbin/postalias][inode][25433][25404] [213][server][cmp][/usr/sbin/postalias][ctime][Fri Jun 30 03:20:49 2006][Sat Aug 12 04:02:21 2006] [204][server][cmp][/usr/sbin/postcat][checksum][fc47304764134988383104ef304f60252dcae749][df49b7fa733d217bb7f0ccec4d7b24b1417f8d21] [206][server][cmp][/usr/sbin/postcat][inode][22626][25579] [213][server][cmp][/usr/sbin/postcat][ctime][Fri Jun 30 03:20:48 2006][Sat Aug 12 04:02:20 2006] [204][server][cmp][/usr/sbin/postconf][checksum][f9d25482431b3a5988e1025bb8abc5033a7517cb][86f6fb5dec3746aa6879a57f1acfac6dac31b85a] [206][server][cmp][/usr/sbin/postconf][inode][25780][25556] [213][server][cmp][/usr/sbin/postconf][ctime][Fri Jun 30 03:20:49 2006][Sat Aug 12 04:02:22 2006] [204][server][cmp][/usr/sbin/postdrop][checksum][6c46e31450d7ac78dce9e840310af5859517eeeb][4409c5e06ec3e9c4e95bbec1ac46e2127cc6e568] [206][server][cmp][/usr/sbin/postdrop][inode][25556][26239] [213][server][cmp][/usr/sbin/postdrop][ctime][Fri Jun 30 03:20:49 2006][Sat Aug 12 04:02:22 2006] [204][server][cmp][/usr/sbin/postkick][checksum][22f2b85a6e64a9828ed2d715464d4252177049f9][174444e88e6a6225a5be5cf91b96a79bffcee751] [206][server][cmp][/usr/sbin/postkick][inode][26373][25973] [213][server][cmp][/usr/sbin/postkick][ctime][Fri Jun 30 03:20:49 2006][Sat Aug 12 04:02:22 2006] [204][server][cmp][/usr/sbin/postlock][checksum][8f294ff26d9ae1cc310c66067eb681fc73d87adc][1615d52feaab658f03ebb2f8b48886998722a478] [206][server][cmp][/usr/sbin/postlock][inode][26379][22379] [213][server][cmp][/usr/sbin/postlock][ctime][Fri Jun 30 03:20:49 2006][Sat Aug 12 04:02:22 2006] [204][server][cmp][/usr/sbin/postlog][checksum][05e084e009f24c6dfec12569fee9c2244495fc0f][39974a2952de785a4eb348c21a01e6caa5c666be] [206][server][cmp][/usr/sbin/postlog][inode][24994][22800] [213][server][cmp][/usr/sbin/postlog][ctime][Fri Jun 30 03:20:50 2006][Sat Aug 12 04:02:21 2006] [204][server][cmp][/usr/sbin/postmap][checksum][61a735999ec1ad6d865fceec01f1c21c78627519][9208a41a41b480664cb0110b945b206b1621fc3d] [206][server][cmp][/usr/sbin/postmap][inode][25404][25310] [213][server][cmp][/usr/sbin/postmap][ctime][Fri Jun 30 03:20:49 2006][Sat Aug 12 04:02:21 2006] [204][server][cmp][/usr/sbin/postqueue][checksum][67e91f182df00d3f1f37a6877bb8d82447eeb705][1c8a80fe7622f6ab8d5b80d5758cd478b430ec68] [206][server][cmp][/usr/sbin/postqueue][inode][26375][26254] [213][server][cmp][/usr/sbin/postqueue][ctime][Fri Jun 30 03:20:49 2006][Sat Aug 12 04:02:22 2006] [204][server][cmp][/usr/sbin/postsuper][checksum][c22c5bb67ae4e726632d882ca500890ad517f8fe][0960a054e31de1e43fceb1a90657eb906cf441da] [206][server][cmp][/usr/sbin/postsuper][inode][21335][26257] [213][server][cmp][/usr/sbin/postsuper][ctime][Fri Jun 30 03:20:50 2006][Sat Aug 12 04:02:23 2006] [204][server][cmp][/usr/sbin/rpc.gssd][checksum][00d368ba2e50ccd8e7818b033ecc2e760482fb58][94cd32ba2be8b42250371bb0b320db885d80ec13] [206][server][cmp][/usr/sbin/rpc.gssd][inode][25317][25133] [213][server][cmp][/usr/sbin/rpc.gssd][ctime][Thu Jun 29 21:43:51 2006][Sat Aug 12 04:02:21 2006] [204][server][cmp][/usr/sbin/rpc.idmapd][checksum][c2e1487fa3a2b3c6920113794aa736cda1afbc23][f64318ecfebef5d775817c31f7125cd24e6c18fe] [206][server][cmp][/usr/sbin/rpc.idmapd][inode][26225][21340] [213][server][cmp][/usr/sbin/rpc.idmapd][ctime][Thu Jun 29 21:43:56 2006][Sat Aug 12 04:02:23 2006] [204][server][cmp][/usr/sbin/rpc.svcgssd][checksum][057aba4745e26e079cdcf3e25ff758a8fe8b99ac][6b5dbe025fee9c33e36143d7b77cd53a60395028] [206][server][cmp][/usr/sbin/rpc.svcgssd][inode][26814][25042] [213][server][cmp][/usr/sbin/rpc.svcgssd][ctime][Thu Jun 29 21:43:50 2006][Sat Aug 12 04:02:21 2006] [204][server][cmp][/usr/sbin/saslauthd][checksum][1aa8edafae567d6b6fb14f2eb49cdf4d830ca279][c3ebd0c10c4cfac0e0f85a91c7f679a149057026] [206][server][cmp][/usr/sbin/saslauthd][inode][26815][26256] [213][server][cmp][/usr/sbin/saslauthd][ctime][Thu Jun 29 21:43:51 2006][Sat Aug 12 04:02:22 2006] [204][server][cmp][/usr/sbin/sendmail.postfix][checksum][50825933dd6029af8aa3c3cb7611a6c5e39252bd][33cc264aec19f9fb6386b6addca71e114cea982a] [206][server][cmp][/usr/sbin/sendmail.postfix][inode][22800][25595] [213][server][cmp][/usr/sbin/sendmail.postfix][ctime][Fri Jun 30 03:20:48 2006][Sat Aug 12 04:02:21 2006] [204][server][cmp][/usr/sbin/smtp-sink][checksum][0cf6dac0dcb97d0910e843bf6a58ee8cec5278b1][3c3a2470a467d258e49eb17af3591fa8cbf20fe6] [206][server][cmp][/usr/sbin/smtp-sink][inode][25310][24994] [213][server][cmp][/usr/sbin/smtp-sink][ctime][Fri Jun 30 03:20:49 2006][Sat Aug 12 04:02:21 2006] [204][server][cmp][/usr/sbin/smtp-source][checksum][892d51b76c4685ac3917c0dad1e0a6fe7ce50cd1][46ad415f1b9dbf6d0761c1f22ee8f12a9f153108] [206][server][cmp][/usr/sbin/smtp-source][inode][22958][26253] [213][server][cmp][/usr/sbin/smtp-source][ctime][Fri Jun 30 03:20:48 2006][Sat Aug 12 04:02:21 2006] [204][server][cmp][/usr/sbin/stunnel][checksum][77254c773406659daab7d70cb190a82b3b45d4cd][561ea970463ccc9ef6ef7f78eb26681645c24a31] [206][server][cmp][/usr/sbin/stunnel][inode][21340][21335] [213][server][cmp][/usr/sbin/stunnel][ctime][Thu Jun 29 21:43:56 2006][Sat Aug 12 04:02:23 2006] Change Statistics: ---------------------------------- checksums: 27 SUID files: 0 root-owned files: 29 file permissions: 0 new: 0 missing: 0 total differences: 85 kfx.

3 5

AMD AM2 motherboard with supported SATA chipsets
by Feizhou 14 Aug '06

14 Aug '06

Hello all, Anybody know of any good and reliable AMD AM2 socket motherboards with SATA chipsets that support NCQ such as SIL3124, NForce 570 Ultra and offer six or more SATA channels?

1 0

proftpd problem
by nightrid3r 13 Aug '06

13 Aug '06

i installed proftpd on a fully updated centos 4.3 server. the servers sits on a private lan (192.168.1.*) when trying to acces the ftp (both from inside the lan and from outside trough a nat router) i cannot login port forwarding is ok as i can enteer both username and password error : 530 login incorrect any ideas? thanks

5 4

Problems with x86_64 kickstart
by Tracy R Reed 13 Aug '06

13 Aug '06

I have successfully set up a very nice kickstart install with the i386 version of CentOS 4.3 and it works great. I am using a custom kickstart script and the kernel and initrd from disc1/images. But when I try to duplicate this for a 64 bit setup (changing paths in my tftp server, ks.cfg, etc to point to the 64 bit stuff) it successfully tftp's everything just as it should (tethereal output follows): 0.000000 192.168.0.201 -> 192.168.0.7 TFTP Read Request, File: linux-install/pxelinux.0, Transfer type: octet 0.002503 192.168.0.201 -> 192.168.0.7 TFTP Read Request, File: linux-install/pxelinux.0, Transfer type: octet 0.039763 192.168.0.201 -> 192.168.0.7 TFTP Read Request, File: linux-install/pxelinux.cfg/01-00-0c-29-14-3a-c5, Transfer type: octet 0.045674 192.168.0.201 -> 192.168.0.7 TFTP Read Request, File: linux-install/msgs/boot.msg, Transfer type: octet 0.522788 192.168.0.201 -> 192.168.0.7 TFTP Read Request, File: linux-install/CentOS4.3/x86_64/vmlinuz, Transfer type: octet 2.487047 192.168.0.201 -> 192.168.0.7 TFTP Read Request, File: linux-install/CentOS4.3/x86_64/initrd.img, Transfer type: octet But then it never tries to get the ks.cfg. I am booting it with: label centos kernel CentOS4.3/x86_64/vmlinuz append initrd=CentOS4.3/x86_64/initrd.img ramdisk_size=7000 ksdevice=eth0 ks=http://192.168.0.7/network-install/ks.cfg.x86_64 (that last line should be all one line) in the /tftpboot/linux-install/pxelinux.cfg/01-00-0c-29-14-3a-c5 config file which it tftp's so it should know that it needs to get the ks.cfg.x86_64 file. I have this same setup working for i386 and it seems to work fine. I would guess there might be some difference in the initrd's but for some reason /linuxrc is a symlink to sbin/init which is a binary executable instead of a shell script. Anyone know why it isn't a shell? And why would my x86_64 kickstart be behaving different from my i386? Any help is very much appreciated! -- Tracy R Reed http://ultraviolet.org A: Because we read from top to bottom, left to right Q: Why should I start my reply below the quoted text

3 6

cpuspeed causing hangs on warm boots
by Dan Halbert 12 Aug '06

12 Aug '06

We are using CentOS-4.3 (x86_64) with Opteron servers, and noticed a problem with cpuspeed: If we reboot by doing "# reboot" or similar from a shell, the boot will hang not long after cpuspeed starts. The machine freezes: ctrl-alt-del doesn't work, and only pressing the reset button or a power cycle will restart the machine. If we reboot from power-up or by pressing the reset button, there is no hang, and the boot proceeds normally. Another strange thing is that only some boxes have this problem. Others, seemingly identical, reboot just fine. We've compared the BIOS settings, the CPU steppings, etc., and they seem to be identical. It's very odd. Maybe we're missing a BIOS setting, but we couldn't find a difference. We've fixed this just by turning off the cpuspeed service. It took some trial and error to figure out this was caused by cpuspeed. Misleadingly, the hang doesn't occur immediately after "Starting cpuspeed: [OK]" prints. Instead it occurs when trying to bring up a network interface, which is almost right after cpuspeed starting. With the original 2.6.9-34.ELsmp, it's at "Bringing up interface eth0". With the 2.6.9-34.0.2.ELsmp (and all other rpms updated), it hangs at "Bringing up loopback interface". This may just be a timing thing. We can just forget about cpuspeed, but if any of you have any advice, we'd appreciate it. Otherwise I am basically posting this to save diagnostic time for those who encounter these symptoms in the future. These are dual-core dual Opteron 265/270 servers with Tyan K8SD Pro motherboards. Thanks, Dan

2 1

RE: [CentOS] yum updates
by Bowie Bailey 12 Aug '06

12 Aug '06

Johnny Hughes wrote: > On Tue, 2006-08-08 at 13:08 -0400, Bowie Bailey wrote: > > Johnny Hughes wrote: > > > > > > (or you can remove the package with rpm -e kernel-smp-devel ... then > > > > > > yum install kernel-smp-devel-2.6.9-34.0.1.EL.i686 > > > > > > or > > > > > > yum install kernel-smp-devel-2.6.9-34.0.1.EL.x86_64 ) > > > > I found the updates repo shortly after sending the first email. I > > followed your second suggestion and was able to have "yum install" see > > it after removing the old package. > > > > Why is the "rpm -e" required? It seems like I should be able to do > > "yum update" and specify the package version as long as it is newer > > than what is currently installed. > > > > Yum has no option to install an older file on top of a newer file > > An update probably installed the 34.0.2.EL-xxxx-devel file ... so 34.0.1 > will never install instead of the newer one. The installed package was older. I have already removed the package on the system I was working with, but here is an example from another one that is identical except for being x86_64 instead of i686. # yum info installed kernel-smp-devel Installed Packages Name : kernel-smp-devel Arch : x86_64 Version: 2.6.9 Release: 34.EL Size : 11 M Repo : installed # yum update kernel-smp-devel-2.6.9-34.0.1.EL Setting up Update Process Setting up repositories Reading repository metadata in from local files Could not find update match for kernel-smp-devel-2.6.9-34.0.1.EL No Packages marked for Update/Obsoletion I have verified that the package does exist in the repo: kernel-smp-devel-2.6.9-34.0.1.EL.x86_64.rpm It looks like a "yum update" will only update to the newest package version. -- Bowie

2 1

yum not showing mirror with php/mysql
by Melinda Odom 11 Aug '06

11 Aug '06

Hi, I have had a new server installed using CentOS 4.3 and no matter what settings I try in the /etc/yum.repos.d/CentOS-Base.repo file I cannot get the CentOS mysql and php which are clearly listed in this mirror to even show up: http://mirror.centos.org/centos/4/os/i386/headers/ and only get this: Setting up repositories Reading repository metadata in from local files This is the CentOS-Base.repo listing: [base] #name=CentOS-$releasever - Base name=CentOS-4 - Base #mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch &repo=os #baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/ baseurl=http://mirror.centos.org/centos/4/os/i386/ gpgcheck=1 gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-centos4 I have tried this with the same results: [base] name=CentOS-$releasever - Base #name=CentOS-4 - Base mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch& repo=os #baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/ #baseurl=http://mirror.centos.org/centos/4/os/i386/ gpgcheck=1 gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-centos4 I have also tried both listings with the gpgcheck=1 and gpgkey=etc.. commented out # with no success. I appreciate any help with this. Sincerely, Melinda Odom Design Hosting, Inc. www.designhosting.biz 479-471-0891 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.405 / Virus Database: 268.10.9/416 - Release Date: 8/10/2006

3 2

Server Hacked: Cpanel
by Timothy J Rice 11 Aug '06

11 Aug '06

cPanel or ANY server solution should never be deployed until it is locked down! We have been using cPanel for years as well as Hsphere and Plesk for both linux and windows. They all are hackable if not locked down and hardened. We use Trustix, RHEL & CentOs for our Linux environments. The more you allow (in cPanel or any control panel), the less secure. Fix the tmp directory BEFORE you plug it in to the network. File there should NOT be executed by ANYONE. About 3 and a half years ago, we learned this the hard way and every index.* file on a particular server that had cpanel installed was defaced (RH 7 I believe). This was NOT a cPanel issue. It was a combination of a PHP exploit, tmp not being secured, and my lack of knowledge. cPanel has a utility to secure the tmp directory. On a machine that has cPanel installed type the below command: /scripts/securetmp I have never had a problem with this sort of attack after I secured the tmp directory. I also recommend not giving shell access by default. Only give it out to people who need it. Make it a little difficult for the end user. Ask them them to fax a copy of their DL and/or copy of the first page of a utility bill. Sure a bad person can create these documents, but it typically is not worth their time. Also if a user needs ssh bad enough, they will send this info in and they probability will be good users. It also lets them know that you are "security conscious". You can also install a keystroke auditing system such as eas / easd so you can review ssh sessions should you suspect something. If you grant a user ssh rights, reset the end users password to a secure password and let them know that they should maintain a strong password. If their account is bruteforced due to a weak password, cancel their account, as they are too much of a risk for you (or ask them to go dedicated). Install some type of BFD (Brute Force Detection) software. I like http://www.rfxnetworks.com/bfd.php (free and easy to install) Disable things like gcc, wget, lynx . . .etc. I also like to chattr +i files. A very good application is another product from rfnetworks called LES http://www.rfxnetworks.com/les.php Disable root direct login via ssh. Block all incoming traffic except needed ports in iptables (22, 80, 443, 21, . . . ). I like to block all outgoing traffic to all users except for root with the exception of common API's such as Domain registration, Credit Card Gateway etc.) Enable suexec and php safemode if possible. Also disable the mod_dl and other php modules known to have caused problems. If you have users who need every module known to man, setup a server with the php modules needed and only place these users on these systems who specifically need them. Why introduce more risk to users who do NOT need all these features? Install mod_evasive to help against Ddos as well as Mod Security. Run updated rootkit checkers (rkhunter & chkrootkit) daily. This is not perfect, but it will help determine a systems integrity. If a machine has been hacked or owned - you MUST setup a new machine and restore the non binary files to the new machine. This is the sad truth, but you never know what is hiding on a machine after its hacked (owned). Do NOT allow cPanel to automatically update your software or you are asking for problems. Have a cheap server or virtual server with cpanel running on it and update that "test" machine and make sure that nothing breaks. We have 50 beta users who we give hosting to. We place on these users on beta (test) machines. The beta users are aware that these machines are at greater risk than the production machines and they are 100% responsible for backups. It is worth giving away 50 free accounts and place them on test beta platforms so that we can actually simulate a "real" environment while testing cpanel upgrades. If testing is successful, then roll out in production. cPanel has broke many things in the past that were easily fixed by their support staff but why take chances??? I recommend the above measures for any system (cPanel installed or not). cPanel is the most popular control panel for Linux. It allows the end user to control their site and cpanel ties into many billing systems so account provisioning can be automatic. We use it because it offers features that end users demand. Without it, we can't compete . . . so we have to adapt by securing the system as much as possible. Tim Rice Host It Now Networks http://hostitnow.com/ Timothy Rice Host It Now Networks http://hostitnow.com

1 0

Server Hacked: Cpanel
by Karl Balsmeier 11 Aug '06

11 Aug '06

Hi, I have servers of mixed OS, some Centos, some Fedora, and after the flame war that erupted last week (where I said basically nothing and just watched), my server was hacked by this team of hackers, actually their friend: http://www.sibersavascilar.com/ This made Karanbir's statements about mixing Cpanel and Centos (any maybe any linux distro) come true very quickly. If one of the top package maintainers says this, it bears weight. I'd like to know more about this subject, specifically on the package front, for security's sake. Karanbir, can you restate the issues with Cpanel please? They are trying to recommend CentOS as the OS to install on, and even that Linux Journal article did -and before anyone else wastes their time, -let's get everything out in the open so that there's a pipermail archive trail for future folks 'googling' for info later on pros/cons of using, or avoiding use of, non-complimentary projects/technologies. Is the issue that both parties maintain separate packaging/updating regimes and have little or no successful communication as far as keeping thing secure and up to date? That seemed to be what you said, -and if I had the old email, i'd just run with it's advice. Also, can you list the IRC channels you mentioned last time that contain the various hackers bragging about freshly broken Cpanel/Centos builds? Freenode right? Any others? I've been on IRC back when BITNET was still active and there wasn't even mosaic yet, but have always avoided it after 1992 because of hackers 'sniffing for future targets'. William, Jim, Johnny, -any comments are truly welcome, -anyone really. Basically i'd like to help stop or curtail the 'open season' this set of circumstances is creating for hackers, -I have already decided to avoid Cpanel on Centos as it is, -my server that was hacked with Cpanel was not a Centos box, and those that have it, have been shut down. The server next to it was *also* hacked, and that *was* a centos machine, with only a yum update from 3 days prior. Is it really recommeded that I run yum update evry night then? It was stunning to have a box up for 3 days and then get owned so fast. Luckily this was for my personal business entity, and not my full-time job, which indeed does run 50-70 Centos servers behind layers of firewalls and other protections, and *no* commercial products, only centos packages by Dag or Karanbir. To anyone in the mood for scolding, please hold off OK? I'm not in the mood for overbearing attitudes right now. I'm trying to run a business and seek solid answers. I see Centos as a reliable alternative to commercial offerings *if* you pay careful attention to what the senior staff and relevant discussion groups advise. As for the team of hackers, if anyone knows who this is, or can point out who they might be or how to ban them, -that is also most welcome. Hacked By Crackers_Child For Peace DONT WAR ! Greetz : X_Alperen_X, XTech Inc , Metlak, Root_Mor,Dr Hacker, Dr.Jr7 ,Dr,Dermann,Code_Power,CukurOvalý ALL My Friends And All SiberSavascilar.Com Members ! --------------------------------- Stay in the know. Pulse on the new Yahoo.com. Check it out.

9 23

Lang packs (extensions) not found with firefox-1.5.0.5-0.el4.1.centos4 ?
by Vincent Knecht 11 Aug '06

11 Aug '06

Hello, with CentOS 4.3 (i386), after updating firefox to 1.5 from update repo, I can't get it to have menu in my native language (french), altough french language pack appears in extension list. I've tried many things, like moving it on top/down, disabling/removing other languages packs, creating a fresh new user, and reinstalling firefox, to no avail (yes, I restarted firefox between these attempts). I also searched in upstream's bugzilla, and didn't find any issue for v4 & firefox... Finally, launching firefox through strace, I find that it searches for /usr/lib/firefox-1.5.0.5/chrome/fr-FR.jar and can't find it, since french lang pack seems to be /usr/lib/firefox-1.5.0.5/extensions/langpack-fr(a)firefox.mozilla.org/chrome/fr.jar I filed the issue in CentOS bugtracker: http://bugs.centos.org/view.php?id=1442 PS: if that matters, I'm using KDE from kde-redhat repo...

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss