Mmmh, I see that it's a pain for you... Sorry for rubbing salt in the wound. Chris has explained well too.
OK. Just a last thing, with no relation to that, but I don't think that it's maybe not necessary to begin a new post for that : do you know if someone works or has at least begun a french translation of the interface ? And is this link : http://www.bluequartz.org/docs/translate/index.html valid for BlueOnyx ? Thank you two. Le 04/04/2012 16:17, Michael Stauber a écrit : > Hi Frank, > >>> Generally you shouldn't modify your sendmail.cf. Any modification should >>> go into sendmail.mc, which our updates will never overwrite. So whenever >>> sendmail.cf is rebuilt from the sendmail.mc during an update, your >>> changes will be retained. >> Are you sure ? When I modify the .cf, I need to compile the .mc file as >> sendmail only know this one. > Yes, I am sure. The sendmail.cf is compiled from the sendmail.mc, so your > changes ought to go into sendmail.mc > >>> As for the AdmServ configuration: This is a "no-go territory". You >>> should not modify AdmServ's configuration for any reason. If you do so, >>> then that will always be at your own risk and will always be entirely >>> unsupported and highly discouraged. >> I understand that it's unsupported, of course. I just wondered if it was >> not an option in yum, maybe... > No, sorry. > >> Yes, but the 5107 and 5108 are based on Scientific Linux and it's >> problematic for some clients, convincing them to use CentOS instead of >> RH was already complicated, so Scientific Linux.... > Yes, I'm just at the end of a tree day ordeal to build an updated CentOS-5 > install CD. See: > > http://www.blueonyx.it/index.php?mact=News,cntnt01,detail,0&cntnt01articleid=124&cntnt01origid=62&cntnt01pagelimit=100000&cntnt01returnid=62 > > For the last three days I've been cursing like a drunk sailor at Karanbir and > the entire CentOS team for delivering such a piece of sh*t (excuse my French) > distribution like CentOS-5. No, I'm really not the least bit amused and just > had it with CentOS. > > Compared to Scientific Linux (both SL-5 and SL-6) CentOS-5 and CentOS-6 are > lightyears behind. This starts with availability of major and minor updates > (where CentOS never seems to see the light of day). > > But it also involves outright snobbism of CentOS, which goes like this: "Oh, > we know that this is broken. But we only tell you if you ask. And no, we won't > fix it. At least not until upstream (RHEL) has fixed it. And even then you > have to wait for a few extra weeks, because we're busy with woreshipping > Karanbir and he will only release updates once we have sufficiently sweet- > talked him into pushing the button." > > Like Chris said: SL is binary compatible to CentOS and whatever was compiled > to run on either RHEL or CentOS will run on the same version of SL. So there > is no good reason to choose CentOS over SL. Only a ton of bad ones, which > includes simply not yet knowing SL to begin with. Yeah, I know. This is a > problem. > >> I know that you had already have this remarks and that you are working on >> the CentOS6 release, right ? > Yes, with much sadness and regret I must say that I will be working on a > CentOS-6 version of BlueOnyx. I really do NOT want to and it is silly, because > CentOS just plain sucks. But will have to do it to offer an alternative to > those who don't know a better Linux distribution even if it falls right into > their laps<sigh>. > > One of the most hillarious good reasons (besides it's quality - of course) to > choose Scientific Linux is this: It is made by Fermilabs and Cern. So no > matter if you live in the USA or in Europe: This is basically the best and > most productive tax return that you'll ever get. Because the development of > Scientific Linux is basically funded with your tax money. ;-) > >> If it's so, I suppose there is no possibility to just install the >> "base-*" files from 5607 or 5608 on this boxes, by modifying the yum >> repos, and keeping the PHP5.3 installed ? > Hell, no! > > Look at this URL: http://devel.blueonyx.it/trac/browser/BlueOnyx > > Except for ... > > base-alpine > base-admserv > base-blueonyx > base-java > devel-tools > i18n > > ... all the base-* modules are identical between 5106R, 5107R and 5108R. > > Some modules (that are identical) just check on installation which platform > they are being installed on and may then make some post-install adjustments to > get things right. > > Mixing repositories is a receipe for desaster. That's like crossing the beams > in Ghostbusters and will lead to a spectacular self destruction. > > Even if you just try to force the 5107R RPMs into a 5106R box, then that won't > work either, as both use different versions of RPM. So the 5106R box can't > even open the RPMs. And if it would, the dependencies would fail due to > different GLIBC versions. > >> The servers where the webUI was broken was 5106, but was up-to-date >> (redhat-release say "5.8"). Do you mean that the files are updated but >> always for a version 5.1 of PHP ? Do you maintain 2 branches, for PHP >> 5.1 and PHP 5.3, of the UI ? > See above. Yes, we have three code branches: > > One set of code with the above listed modules for 5106R only. > > One set of code with the above listed modules that works on 5107R and 5108R > only. In SVN that's the 5107R code branch. > > Then there is the third branch of modules (which contains the majority of the > modules) that will compile and run anywhere. They're in the "ui" and "utils" > directory. > >> To be clear about the problem described, I haven't *moved* the admserv >> directories, but *copied* them in another location. So the updates of >> "base-*" have been applied in the original directories. When the files >> php.ini and php.conf were replaced, the pathes returned to these >> directories, and then admserv restarted with the installed PHP : 5.3.8, >> but in error. > Yes, but sadly that approach is flawed to begin with. Yes, it works. But for > how long? Well ... until the next major update. And then it breaks hard again. > > The third party PHP modules from Solarspeed and Compass Networks use a > different approach: The third party PHP is installed into a separate path. The > public Apache then uses the third party PHP, while AdmServ remains unchanged > and continues to use the OS supplied original PHP. > > This causes no conflict and will survive through any minor and major YUM > updates without any problems. > >> About that, can you tell me if the prices given on Solarspeed for >> example are a definitive prices, or a yearly (monthly ?) rental ? > At the present the Solarspeed PHP is a one time purchase per server. But > sometime near the end of the month there will be an optional subscription > model for updates. So whatever the latest PHP is, if you go for the > subscription model you always get access to the updates and can install them > through the GUI at a time of your choosing. > _______________________________________________ Blueonyx mailing list [email protected] http://mail.blueonyx.it/mailman/listinfo/blueonyx
