Re: [CentOS] Problems with Adobe flash-plugin and Firefox-3.5.x under CentOs-5.3 (yum up to date) = libcurl.so.3/libcurl.so.4 missing
On Sat, Sep 19, 2009 at 6:58 AM, Martin Knoblauch spamt...@knobisoft.de wrote: - Original Message From: Martin Knoblauch spamt...@knobisoft.de To: Centos Discussions centos@centos.org Sent: Monday, September 14, 2009 3:16:20 PM Subject: Problems with Adobe flash-plugin and Firefox-3.5.x under CentOs-5.3 (yum up to date) Hi, I am running 32-bit Firefox-3.5.3 on Centos-5.3 (64-bit kernel) on a Dell Precision M65 laptop. This is likely a Adobe problem, but maybe someone else has seen this before. Please CC me, as I only receive the digest version of the list. When using the 10.0.32.18-release version of the flash-plugin, trying to access *any* page containing flash (e.g. www.adobe.com) causes the browser to die. This also happens with version 10.0.22.87. Version 9.0.115.0 works fine. To avoid problems with add-ons, Firefox is started with -safe-mode. As far as I know, the problem also happens with Firefox-3.0.x. # uname -a Linux l6g0223j 2.6.18-128.7.1.el5 #1 SMP Mon Aug 24 08:21:56 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux # rpm -q flash-plugin flash-plugin-10.0.32.18-release Any idea? Anything I can help debugging the problem? The problem turns out that libflashplayer.so (Version 10.x) is looking for dynamically loading libcurl.so.3 or libcurl.so.4. This dependency is neither documented, nor present in the flash-plugin RPMs from Adobe (both 32- and 64-bit). The dependency probably should also be present in the firefox RPM itself. I found out by chance when the problem went away after installing the curl.i386 package to get firefox building on my system. Cheers Martin ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos Documented here under dependencies: http://kb2.adobe.com/cps/153/tn_15380.html ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Cloud Computing
- Original Message From: Tsai Li Ming lt...@osgdc.org To: CentOS mailing list centos@centos.org Sent: Monday, July 20, 2009 12:18:26 AM Subject: Re: [CentOS] Cloud Computing Hi, Bogdan Nicolescu wrote: - Original Message From: Ryan J M To: CentOS mailing list Sent: Saturday, July 18, 2009 8:59:02 AM Subject: Re: [CentOS] Cloud Computing On Sat, Jul 18, 2009 at 4:36 AM, Mattwrote: Is anyone creating a cloud based on Centos yet? Ubuntu seems to be quite active there: http://www.ubuntu.com/products/whatisubuntu/serveredition/cloud/uec So there still has no CENTOS HPC solution provided yet, has upstreamer disclosed the source? ftp://ftp.redhat.com/pub/redhat/linux/beta/RHHPC still not accessable. If the centos community wish to obtain the srpms directly from us, I can provide them as rhhpc srpms are obtained from us. As expressed before to the community here and to KB, we are willing to help build and contribute to the CentOS HPC SIG. -Liming ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos Yes, please do provide the srpms thanks bn ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Cloud Computing
- Original Message From: Ryan J M sync@gmail.com To: CentOS mailing list centos@centos.org Sent: Saturday, July 18, 2009 8:59:02 AM Subject: Re: [CentOS] Cloud Computing On Sat, Jul 18, 2009 at 4:36 AM, Mattwrote: Is anyone creating a cloud based on Centos yet? Ubuntu seems to be quite active there: http://www.ubuntu.com/products/whatisubuntu/serveredition/cloud/uec So there still has no CENTOS HPC solution provided yet, has upstreamer disclosed the source? ftp://ftp.redhat.com/pub/redhat/linux/beta/RHHPC still not accessable. -- FIXME if it is wrong. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos RedHat HPC = Platform OCS (www.platform.com) + RHEL + kits http://vglug.info/files/HPC_Webinar_1-15-09.pdf (mentions platform OCS) http://www.redhat.com/docs/en-US/hpc/1.0/pdf/Installation_Guide.pdf kits = a base kit, in this case RHEL and few self contained cluster-oriented applications (i.e. openmpi, lava, ganglia) RedHat HPC comes with the two DVDs. One DVD containing Platform OCS, second DVD contains RHEL and a few (8-10) kits. When installing RedHat HPC, first you boot in Platform OCS (which itself is based on RH), you go through some basic configuration, and then you are asked for the kits. You insert the RHEL+kits disk, where it extracts the RHEL base and various kits. Instruction's in RH Installation guide assumes you are installing OCS on top of RH. I only did a fresh installed so I started with OCS, and added RHEL as a kit. - previously Platform OCS (version 4) was based on Rocks Linux, and old docs might not be compatible. currently Platform OCS (version 5) is based on open source Project Kusu (http://www.hpccommunity.org/). Project Kusu seems to be now part of www.platform.com - now for Centos HPC. go to http://www.hpccommunity.org (currently down on my end), go to project kusu, and pick up the Centos installer, configured to work with Centos, (burn iso image). This is the first disk, the equivalent of Platform OCS. Assuming a new installation, and not an installation of kusu on top of centos. Boot using Kusu disk. Go through the setup, and at some point you'll be asked to install kits. Here, you insert the DVD containing Centos 5.3 Kusu comes with 2-3 kits, but installing new kits is not too difficult (see kusu docs), and probably a good practice in case you have to install a non-preconfigured kit, ie intel compiler. Unfortunatelly, based on the forum activity hpccommunity.org doesn't seem to be a very active community. Also hpccommunity.org was previously http://osgdc.org/ (probably before merging with platform.ocs). Another project which seems to have branched off, and share a base with kusu is unicluster - www.grid.org parent company univaud.com. Unfortunatelly, this too is as active as kusu, but there is enough documentation to get it going. - I hope this layering of applications, where RH bundles 3rd party applications and then puts it under the RH hat, doesn't become the norm. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Dag's comment at linuxtag
the end of this circle for me ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Dag's comment at linuxtag
In all fairness to all the rebels, if somebody from the Cento's team would have responded in a timely matter to the original yes/no question of this thread, maybe this thread wouldn't have deviated to the point at which is at. Something definitely got lost in the translation, but in the future, if someone speaks on the behalf of Centos, please make sure that the information remains consistent with Centos' goals. And the goal as far as I can tell is very simple... 100% RH compatibility. Please warn us in advance the moment Centos plans to break 100% RH compatibility. RC, check the original post again, and then your answer. You actually ignore the second half of what you quote, A quick look at http://distrowatch.com/table.php?distribution=centos shows that a great majority of the packages are not even close to being up-to-date, and that is a good thing for those us of who care more about stability than eyecandy you probably didn't even bother to read the rest of the message: From the comment ...latest release has many up-to-date desktop packages and we also have an extra repository with many application and drivers that are not officially part of Red Hat Enterprise Linux (RHEL)... is is safe to assume that future releases of Centos will remain a built from publicly available open source SRPMS provided by a prominent North American Enterprise Linux vendor. CentOS conforms fully with the upstream vendors redistribution policies and aims to be 100% binary compatible. (CentOS mainly changes packages to remove upstream vendor branding and artwork)., AND all additional non-PNAELV packages will remain in the extra repository?? and then you hijack the thread and start talking about version numbers, Dag, repositories, and suitable distros. NO... Dag, suitability, version numbers, and repositories were not the question. Again, the question, which has a rather simple YES/NO answer, and which only someone from the Centos team could answer(and they already did a couple of days ago): is is safe to assume that future releases of Centos will remain a built from publicly available open source SRPMS provided by a prominent North American Enterprise Linux vendor. CentOS conforms fully with the upstream vendors redistribution policies and aims to be 100% binary compatible. (CentOS mainly changes packages to remove upstream vendor branding and artwork)., AND all additional non-PNAELV packages will remain in the extra repository??? The quoted staff is from Centos website. And if you wonder why I asked this question, re-read the orginal post to put the question into context. bn ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Dag's comment at linuxtag
- Original Message From: R P Herrold herr...@centos.org To: CentOS mailing list centos@centos.org Sent: Friday, July 3, 2009 8:51:35 PM Subject: [CentOS] Dag's comment at linuxtag On Fri, 3 Jul 2009, Bogdan Nicolescu wrote: BUT... when someone from the Centos team makes a statement like ...latest release has many up-to-date desktop packages... ummm -- it is of course true that changes happen; rebasings do as well; and the CentOS project [and the upstream] document these matters in release notes as to the up-to-date changes done. Upstream decided on most of them, or we made a minimal delta to get the packageset to stabilize. So what? The project cannot cater to people who won't read nor pay attention. Russ, this was about a comment about up-to-date desktop packages, not a comment about up-to-date changes. Just because the release notes contains up-to-date changes, it doesn't necessarily mean that the up-to-date xxx package is installed. But maybe I wrong, please point to one current up-to-date package in Centos or RH for that matter. And by up-to-date package I don't mean a stable, but un-supported package (ie PHP) I think a lot of users will start looking for alternatives. 'a lot?' ... we disagree Are you disagreeing with the number (a lot) of users who use Centos because they need/want an RH clone, or/and are you disagreeing with the number (a lot) of users who would leave Centos if Centos breaks RH compatibility? It should be easy to find out. Conduct a poll. That said: Choice is good -- keeping an eye on options is good. So what? Choice is good and somtimes overrated, but stability is always better. Straining at gnats and worrying about scope creep by CentOS in 'base' and 'updates' is a wasted effort, so long as one remains in those archives. As I said before, 'no-one forces you to use any third party repository' Thank you, and all the other Centos members for clarifying this... Yes, CentOS is often considered a server operating system, explained Dag, but we are trying to change that. In fact, the latest release has many up-to-date desktop packages and we also have an extra repository with many application and drivers that are not officially part of Red Hat Enterprise Linux (RHEL). And keep up the good work. bn ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Dag's comment at linuxtag
Thanks - Original Message From: Karanbir Singh mail-li...@karan.org To: CentOS mailing list centos@centos.org Sent: Tuesday, June 30, 2009 11:46:15 AM Subject: Re: [CentOS] Dag's comment at linuxtag On 06/29/2009 08:06 PM, Bogdan Nicolescu wrote: The whole point of the question is to make sure that Centos will remain 100% binary compatible with PNAELV, at least in terms of package version. This does not mean that others will not have the ability to break this 100% binary compatibility, at least in tersm of package version, by installing more up-to-date packages from extra repositories. yes. By extra repository(ies) I mean any other repository that contains packages which are not in PNAELV. yes again, and some of these 'extra repos' might be hosted within the project itself. - KB ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Dag's comment at linuxtag
From http://distrowatch.com/weekly.php?issue=20090629 Right next to the Gentoo stand was a group of young people, proudly displaying their affiliation with CentOS. Dag Wieers, the well-known maintainer of a once very popular RPM repository, greeted me with a big smile: Do you know CentOS? When I introduced myself, he looked somewhat disappointed: Oh, so you know CentOS... Still, we found a lot to talk about. Yes, CentOS is often considered a server operating system, explained Dag, but we are trying to change that. In fact, the latest release has many up-to-date desktop packages and we also have an extra repository with many application and drivers that are not officially part of Red Hat Enterprise Linux (RHEL). He asserted: CentOS can be a perfect system for those who need long-term stability and who don't want to take frequent and potentially risky upgrade paths. A quick look at http://distrowatch.com/table.php?distribution=centos shows that a great majority of the packages are not even close to being up-to-date, and that is a good thing for those us of who care more about stability than eyecandy. From the comment ...latest release has many up-to-date desktop packages and we also have an extra repository with many application and drivers that are not officially part of Red Hat Enterprise Linux (RHEL)... is is safe to assume that future releases of Centos will remain a built from publicly available open source SRPMS provided by a prominent North American Enterprise Linux vendor. CentOS conforms fully with the upstream vendors redistribution policies and aims to be 100% binary compatible. (CentOS mainly changes packages to remove upstream vendor branding and artwork)., AND all additional non-PNAELV packages will remain in the extra repository??? thanks bn ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Dag's comment at linuxtag
not to be rude but back to the core of the original question: is is safe to assume that future releases of Centos will remain a built from publicly available open source SRPMS provided by a prominent North American Enterprise Linux vendor. CentOS conforms fully with the upstream vendors redistribution policies and aims to be 100% binary compatible. (CentOS mainly changes packages to remove upstream vendor branding and artwork)., AND all additional non-PNAELV packages will remain in the extra repository??? The whole point of the question is to make sure that Centos will remain 100% binary compatible with PNAELV, at least in terms of package version. This does not mean that others will not have the ability to break this 100% binary compatibility, at least in tersm of package version, by installing more up-to-date packages from extra repositories. By extra repository(ies) I mean any other repository that contains packages which are not in PNAELV. thanks bn ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Processes to disable
- Original Message From: Filipe Brandenburger filbran...@gmail.com To: CentOS mailing list centos@centos.org Sent: Monday, April 13, 2009 6:02:32 AM Subject: Re: [CentOS] Processes to disable Hello, On Thu, Apr 9, 2009 at 10:21, David Lemcoe wrote: a bunch of processes that really aren't needed Yes, many processes started in a default installation are not needed, but they are not harmful at all, and in most cases they will not bring you any problems. On the other hand, if you start disabling processes, you might get into trouble and not know exactly why. So, especially if you are *not* a more experienced CentOS user, I would advise you against disabling processes that you do not know if you need or not. As I said, if you don't really need them, they will probably not be harmful to you. and just burn up processes. This is a very silly argument, it's not like you have a low limit of total number of processes in your system, and so far I have never seen anyone reach that limit. Which ones should I get rid of for just a webserver? MySQL server? If you do not plan to run MySQL server on a machine, then yes, you should disable it, but in that case you should not even have installed the RPM package to start with. In that case, the way I would advise you to disable it is to uninstall the RPM. On Thu, Apr 9, 2009 at 16:29, Bogdan Nicolescu wrote: to disable/enable a service: chkconfig --level service-name off/on i.e. chkconfig --level 3 sshd off Disables sshd for levels 3 chkconfig --level 35 sshd on Enables sshd for level 3 and 5 Never use the --level argument unless you have very specific needs. You should use: chkconfig sshd off And: chkconfig sshd on The service initialization files have a list of default runlevels, which will probably make more sense than anything you specify. http://www.phpman.info/index.php/man/chkconfig/8 Maybe the chkconfig man pages can be revised to include Never use the --level argument unless you have very specific needs because The service initialization files have a list of default runlevels, which will probably make more sense than anything you specify. To see the names of all the services installed on your system: ls /etc/rc.d/init.d Using 'chkconfig --list' makes more sense than listing the init.d directory. chkconfig --list doesn't necessarily list all the services in /etc/rc.d/init.d bn HTH, Filipe ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Processes to disable
- Original Message From: Filipe Brandenburger filbran...@gmail.com To: CentOS mailing list centos@centos.org Sent: Monday, April 13, 2009 6:29:43 PM Subject: Re: [CentOS] Processes to disable On Mon, Apr 13, 2009 at 12:03, Bogdan Nicolescu wrote: To see the names of all the services installed on your system: ls /etc/rc.d/init.d Using 'chkconfig --list' makes more sense than listing the init.d directory. chkconfig --list doesn't necessarily list all the services in /etc/rc.d/init.d It does list all that were properly registered. If a service is not listed by chkconfig --list, it means it was not registered with chkconfig --add, and it probably means that there was a problem while installing the package. AFAIK, if it does not show in chkconfig --list you will not be able to activate it with 'chkconfig on' either. Filipe Not properly registered with chkconfig doesn't necessarily mean that a service is not installed. service --status-all is probably a better choice in finding the status of all the scripts in init.d, and not just those registered withc chkconfig. bn ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
