--- UNIX admin <[EMAIL PROTECTED]> wrote: > > For system performance and sometimes stability in > > certain scenarios due to bug fixes. We do not care > > too > > much about API/ABI stability. Much of what we need > > either comes with the distribution or needs to > have a > > internal package made. > > Such things are so strange to read about if you come > from a Solaris environment... those things are > foreign to me.
Of course they are foreign. You do not have the means for the kind of environment I was in. > > > Not every production system that exists out there > > runs > > legacy binaries. > > Yeah, well, what do you do if you have about 2,500 > applications already running? The cost of adaptation > would be trumendous, not to mention how many > hundreds or thousands of man days it would take to > get the job done. Yawn. > > > When we are the system engineering department and > we > > need to make these boxes perform with more > efficient > > code/features. > > Regular engineering release cycles? RIGHT...for a modified sendmail that does not change at all save for security exploits...hmm...you really have a closed mind. The only 'engineering' needed here would be how to quickly replace the OS with a more efficient one and making sure that the OS gets its security holes plugged quickly without breaking anything. > > > You work in a different environment with different > > needs. > > I don't believe so. Why? Because the methodics we > use would be a cure for ad-hoc environments. Those methodics are so exclusive to Solaris. > > > I had perfectly fine stuff running on FreeBSD that > > won't crash. The problem was, it was really slow > in > > performance and in the end, I had them all ripped > out > > and replaced with Linux to get twice the > deliveries > > and get more smtp transactions handled. We > obviously > > do not care about 'stability'. > > What about "time to market"? Service response? Rapid > deployment? Huh? What is going to beat automatic updates? > > I'm able to provide a fully running and configured > server or servers, hundreds of them, within a few > minutes. Exactly the thing an ad-hoc environments > strive for, but never manage to meet. That's my > point. yeah, nothing like flar exists outside of solaris. Which planet do you live on? You would never imagine images + automatic updates because you cannot do that in Solaris. All you can do is maintain staging box and flar out when you are happy with staging box. > > > Very nice. Not impressed however. We had one or > two > > linux boxes like that. They have been running for > > over > > two years without a reboot and we were worried > that > > they would fail to boot if they did crash or > suffered > > a power loss especially since they were the boxes > > that > > only ran an old copy of forum software. > > Automated clustering solution? Those boxes were not mine...in fact they were nobody's...I remember now...one of them ran that old forum software while the other ran some anti-virus scanner for the webmail system...is that what happens to Solaris boxes that have been running for years on end without anybody patching them? > > > The current way software on Solaris is managed, oh > > yes > > it will need plenty of babysitting in our > > environment. > > For example, sendmail was patched to add mysql > table > > support. sendmail, being the security exploit > prone > > piece of software that it is, gets frequent > updates > > that fix security holes and some of them are root > > exploits. You can bet that any sendmail 'patch' > for > > Solaris 10 will break our system. Would we dare > > automate security fixes? The current software > > management via patches is not transparent and a > pain > > to keep an eye on because you have to look to find > > out > > what comes in the patch. We dare not automate any > > updating for security holes because who knows what > it > > will clobber? > > su - > Password: > > svcadm disable svc:/network/smtp:sendmail > pkrgm -n SUNWsndmr SUNWsndmu > > pkgadd -a /var/opt/abcd/sadm/install/admin/admin > /net/software-repo-server/spool/pkg/ ABCDpostfixuser > ABCDpostfixlanconfig ABCDpostfix > > svcs -xv svc:/network/smtp:abcd_postfix > online May_16 > svc:/network/smtp:abcd_postfix > > And that's just an *interactive* example; note that > no configuration has been performed, just the > software installed, and it's running and serving > already (preconfigured via ABCDpostfixlanconfig > package). I like the installation process already doing the right thing. Or do I have to fling 'service sendmail stop; rpm -i postfix.rpm; rpm -i postfix-configs.rpm; service postfix start; chkconfig --level 2345 postfix on' too? > > In reality, those packages would have been removed, > and Postfix packages would have been added by a > central software deployment server, with two or > three clicks in a web browser. Right. This from the CLI guy? Click Click Click? Send instant messages to your online friends http://uk.messenger.yahoo.com _______________________________________________ opensolaris-discuss mailing list [email protected]
