The VAR supports Apache on linux and IIS on Windows. We might ask them this
again.
Thanks.  --dawn


On Wed, Jul 17, 2013 at 10:33 PM, Daniel McGrath <
dmcgr...@rocketsoftware.com> wrote:

> Any reason you cannot do Apache on Windows?
> ________________________________________
> From: u2-users-boun...@listserver.u2ug.org <
> u2-users-boun...@listserver.u2ug.org> on behalf of Dawn Wolthuis <
> dw...@tincat-group.com>
> Sent: Wednesday, 17 July 2013 8:26 PM
> To: U2 Users List
> Subject: Re: [U2] CentOS with Universe?
>
> Thanks to all who responded. There is plenty of wisdom in the sum of all of
> these posts. We are nailing down costs from the hosting provider for each
> option. It looks like Windows 2008 Standard is less expensive per month
> than RHEL 6 with the hosting site we are using (primarily because of the
> $500 annual cost for RHEL). My colleague uses his own perl scripts with
> apache, so he is not excited about IIS. My only issue with IIS has to do
> with poor experiences to date, but when I check the date, it is somewhere
> around 2001. Perhaps I need not hold a grudge that long?  cheers!  --dawn
>
>
> On Wed, Jul 17, 2013 at 7:48 PM, John Hester <jhes...@momtex.com> wrote:
>
> > Dawn, just to add my 0.02, I have a couple of production CentOS servers
> > but run UV on RHEL.  UV is the most mission-critical app we have and I
> feel
> > it would be too much of a risk to run it on an unsupported platform.
>  And I
> > would take Tony's point that Linux has the exact same update headaches as
> > Windows one step further and say that it's worse.  I choose to run UV on
> > RHEL because I rely heavily on custom UV integration with system
> utilities
> > like cron and open-source apps like postfix, cURL and wget.  Installing
> all
> > available updates a la Windows on the RHEL UV box is something I'd never
> > do, though, because the risk of breaking something is too high.  To give
> an
> > example, I installed all the latest updates on the less mission-critical
> of
> > our CentOS servers a while back and it broke the freeRADIUS service we
> use
> > to authenticate wifi clients via Active Directory.  Fortunately the other
> > CentOS server is a backup freeRADIUS server, but it was still time
> > consuming to fix.  When RH or CentOS updates an app, any config files
> > replaced are backed up in the current location with an extension of
> > ".rpmnew".  When freeRADIUS starts up it reads every config file in its
> > directory regardless of name, so this totally borked the installation.
> >  Fixing it was a matter of opening both the old and new versions of all 7
> > replaced config files in a GUI text editor with diff capability and
> > painstakingly merging the original config into the new files.  I probably
> > spent a couple of hours on it, and that was just one application.  UV is
> in
> > use 24x7 and an outage like that on our UV server would be catastrophic.
> >
> > Having said that, I think a case could be made for running UV on CentOS
> if
> > the initial installation runs stably and you don't plan to patch it.  I
> > would thoroughly test every aspect of UV, but once you're certain it's
> > stable, you aren't likely to need support if you don't break anything
> going
> > forward.  Lack of patches sounds like a security risk on the face of it,
> > but good security isn't a black and white issue.  If no unnecessary
> > services are listening on the box, no end users have direct access to the
> > OS shell, and the box isn't directly open to the internet, it's pretty
> > secure IMHO.  RH may issue a ton of "critical" security updates for
> various
> > services, but if you're not running those services, or if a user needs OS
> > shell access they don't have to execute a privilege escalation, those
> > updates are irrelevant.  There are lots of add'l security measures that
> you
> > can take to further protect the server, such as installing the free OSSEC
> > intrusion detection utility from Trend Micro and running ssh on a
> > non-default port.  As Dan said, the question of whether or not to run UV
> on
> > an unsupported platform really depends on the risk tolerance of the
> client
> > where it's installed and how they're using it.  It's not appropriate for
> > our environment, but if someone else decides the cost savings outweigh
> the
> > risks for them after carefully considering both, I wouldn't necessarily
> > tell them it's a bad idea.
> >
> > -John
> >
> > -----Original Message-----
> > From: u2-users-boun...@listserver.u2ug.org [mailto:
> > u2-users-boun...@listserver.u2ug.org] On Behalf Of Daniel McGrath
> > Sent: Wednesday, July 17, 2013 11:00 AM
> > To: U2 Users List
> > Subject: Re: [U2] CentOS with Universe?
> >
> > In Dawn's case, I agree with Tony. At larger scales though, support from
> > RHEL isn't just bug fixes that CentOS gets eventually, but is also system
> > configuration assistance for issues, particularly around performance. If
> > you are not running a production server yourself, but are using it for
> > development or support, then it is probably less of an issue.
> >
> > If you are running your core business on it 24/7, it's a different story.
> >
> > Dan McGrath
> > Managing Director, U2 Servers Lab
> > Rocket Software
> > 4600 South Ulster Street  ·  Suite 1100  ·   Denver, CO 80237 ·  USA
> > T: +1 720 475 8098 · E: dmcgr...@rocketsoftware.com · W:
> > u2.rocketsoftware.com
> >
> >
> >
> >
> > -----Original Message-----
> > From: u2-users-boun...@listserver.u2ug.org [mailto:
> > u2-users-boun...@listserver.u2ug.org] On Behalf Of Tony Gravagno
> > Sent: Wednesday, July 17, 2013 11:38 AM
> > To: u2-users@listserver.u2ug.org
> > Subject: Re: [U2] CentOS with Universe?
> >
> > > From: Dawn Wolthuis
> > > We have a VAR who would prefer to load Universe and their application
> > > on a supported platform, but we would prefer not to pay for RHEL 6. I
> > > searched the list and found a few tidbits, but does
> > anyone
> > > have a good list of what changes might be required to successfully
> > run
> > > Universe 11.1 on CentOS? How much pain would we be introducing for
> > > ourselves and our VAR, if they were willing to play along?
> >
> > Dawn, you have accurate responses from everyone:
> > 1) Should be exactly the same.
> > 2) Might not be.
> > 3) There is risk involved.
> >
> > Personally I run CentOS whenever I need Linux. But it does have its own
> > errors from time to time, and sometimes it takes a while to get them
> fixed
> > - just visit the CentOS forum and see what people are talking about.
> That's
> > the gamble we take for freeware. (It's only "free" if your time is
> > worthless.)
> >
> > How much does RHEL Support help? Well, many systems I know never even
> > update their RHEL systems. They install and then don't want to patch
> > because it might mess up dependencies, forcing a reinstall. And RedHat
> does
> > the same themselves to an extent - they guarantee that their distro isn't
> > volatile like Fedora - in part because they don't provide many updates to
> > common FOSS after production. As an example, you need an update to
> > something like cURL (v7.19 from the "current" RHEL6 yum update but v7.31
> in
> > real world) you'll have to get it from somewhere other than RedHat, and
> > that could break a lot of stuff. And because they bashed Windows for so
> > many years about this (DLL HELL) before drinking the Linux Kool-Aid,
> these
> > folks are afraid to say Linux has exactly the same problems, or afraid to
> > admit they don't update their system, or maybe they just don't know that
> > their packages are a couple years old and unpatched. (No need for people
> to
> > jump in to reassure us that you update your personal system(s) - trading
> > anecdotes doesn't change the fact that other people do things
> differently.)
> >
> > But the real point here ... is that once U2 is working, and it "should"
> > out of the box, then it "shouldn't" break, as long as you don't change
> > anything. It's been around since 2010 and CentOS is right there with it
> > now. The only time you could have issues is when U2 is certified over a
> new
> > RH release and CentOS hasn't caught up to them yet. The cost for not
> being
> > with a current RHEL release is that you won't be able to install a brand
> > new OS/DBMS combo with confidence, you'll just have to wait a while for
> the
> > dust to settle. Now, what if you do get that brand new release of RH/UV
> and
> > it breaks. You need to wait for Rocket to work with RH anyway. So if
> you're
> > going to wait there anyway, why not just wait a little longer and get it
> > all free?
> >
> > You asked "how much pain would we be introducing" ... all we can tell is
> > how much pain you "could" or "might", not "would". The odds are in your
> > favor - chances are very slim that there will be an issue in RHEL that
> > affects U2, that it will get fixed by RH but not passed on in CentOS.
> > There's just a time delay - you'd be paying RedHat to get changes to you
> > faster, that's all, but you'll eventually get the same changes from
> CentOS.
> >
> > HTH
> > T
> >
> > _______________________________________________
> > U2-Users mailing list
> > U2-Users@listserver.u2ug.org
> > http://listserver.u2ug.org/mailman/listinfo/u2-users
> > _______________________________________________
> > U2-Users mailing list
> > U2-Users@listserver.u2ug.org
> > http://listserver.u2ug.org/mailman/listinfo/u2-users
> > _______________________________________________
> > U2-Users mailing list
> > U2-Users@listserver.u2ug.org
> > http://listserver.u2ug.org/mailman/listinfo/u2-users
> >
>
>
>
> --
> Dawn M. Wolthuis
>
> Take and give some delight today
> _______________________________________________
> U2-Users mailing list
> U2-Users@listserver.u2ug.org
> http://listserver.u2ug.org/mailman/listinfo/u2-users
> _______________________________________________
> U2-Users mailing list
> U2-Users@listserver.u2ug.org
> http://listserver.u2ug.org/mailman/listinfo/u2-users
>



-- 
Dawn M. Wolthuis

Take and give some delight today
_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Reply via email to