Epic fail from RedHat?

[xavi.garcia at gmail.com (Xavi Garcia)]

Hi,

There is a problem with the format of my previous email.

I apologize the inconvenience.

Regards,

Xavier Garcia


2009/11/21 Xavi Garcia <xavi.garcia at gmail.com>

> Michael,
>
> My comments are also inline.
>
>
>
> 2009/11/20 Michael Miller <mike.mikemiller at gmail.com>
>
> Xavi,
> > My comments are inline.
>
>
>
> > On Thu, Nov 19, 2009 at 2:16 PM, Xavi Garcia <xavi.garcia at gmail.com>
> > wrote:
> > > Hi,
> > >
> > > My point as admin., talking about HelpDesk,
> > >
> > > Lets say that I have created my image / kickstart file with the programs
> > I
> > > trust and I have tested myself, so everything works fine and I am sure
> > that
> > > my HelpDesk and secondline guys are properly trained to help the users.
> >
> > Yes, if we all lived in a  perfect world that would be the case.
> >
> > > Now, one example is the email client,  they can choose their own
> > software
> > > that can brake lots of things and Help Desk can't help them because they
> > > can't be trained to support everything that comes from their repository,
> > > unless we maintain a custom repository that will cost lots of money.
> >
> > Some of the above is true. Windows ( not in a Active Directory Domain
> > ) allows you by default to install anything.  I think this was the
> > wrong choice for the default behavior in Fedora.  If you read all of
> > the comments associated with that bug.  Someone pointed out the
> > behavior in question, could be changed and should be in a corporate
> > environment. You can also restrict the selections of software.  Based
> > on the policy of your company.  I still feel letting users install the
> > e-mail application you have standardised on is a good idea.  This will
> > help the users from getting frustrated that they can't do anything
> > with out a support call.
>
>
> It will be a great solution but only if they develop a system that is
> robust and  well
> documented. Reading their mailing list I think that only few guys know
> exactly
> how it works, there is not enough documentation (a FAQ page and some
> blogposts)
>  and the commands/options are changing release after release.
>
>
>
>
> > <side note>
> > A e-mail client ( MUA ) should be apart of any business desktop.  I
> > just want to make sure everyone reading is on the same page that this
> > is just being used as a example.  I don't want to get a bunch of hate
> > mail based on using it as a example.
> > </side note>
> >
> > I don't think your argument about having ones own custom repository
> > leads to costing lots of money.  Most large ( if not all )
> > organizations have second or third tear storage ( SAN array, NAS or
> > JBODS ) that they use for this.  I've not worked in a company that has
> > not had a SMB share or NFS share that didn't have approved software,
> > for IT staff to grab from vs downloading the latest version off the
> > Internet.  If you are following a software patch policy that says you
> > test in a test environment.  Then you install on a development
> > environment before you install in production or in a QA environment.
> > You are going to have to store that somewhere, that is shared. Even if
> > you are doing the install by hand.
> Of course, I have my own repositories in my SAN.  Perhaps I didn't express
> my
> point of view as I should. The point here is that mirroring their
> repository is not
> enough, now. If I follow their default policy, I have to create a custom
> repository,
> only with the packages that I really need and it requires time and tests,
> because
> will have broken dependencies, libraries, etc..
>
>
>
>
> > > From the admin./security point of view, now we do not have a standard
> > > environment and the patch policy is broken because we can't test or
> > > prioritize patches .
> >
> > That's true if you don't change the default policy.   It's the same
> > with anything in the network.  The default configuration is never the
> > most secure.  You only get to a non-standard environment because you
> > don't have defined policies. ( or a defined configuration implemented.
> > ) I didn't mean to say this was a good security practice or policy.  I
> > only pointed out that it's a good idea and can cut down on IT staff
> > having to coddling end users.  ( Why is end user self service not a
> > good idea? ) Which I don't think anyone enjoys doing,  Or having to
> > explain why users can't install approved software with out a helpdesk
> > intervention.  This gives the allusion ( to the end user ) that they
> > have some control.  While allowing IT to control what software and
> > what manner it's installed on the system.  At the end of the day if
> > the user likes using Outlook vs Thunderbird. The company has
> > Thunderbird as chosen e-mail reader.  The user is out of luck and is
> > going to have to learn to use it.
>
>
> I do not know exactly how this installation system  works. Perhaps I can
> create a policy somehow and define the packages that can and can't be
> installed,
> but this adds complexity in the system  and it is dangerous.  I believe
> that least
> privilege is key to secure a system. I am sure that many people in this
> list is able
> to find ways to break this system, because complexity means mistakes and
> mistakes
> mean compromise.
>
>
> > > The worst thing is that this 'feature' was undocumented.  We could
> > accept
> > > that this setting is enabled by default, but we need a
> > guide/recommendations
> > > to harden our environment if we want to deploy FC12.  Change the
> > security
> > > model and keep it secret is bad.
> >
> > This is very true and I fully agree with your statement.  I think
> > Fedora has a lot of egg on their face for this one, as they should.
> >
> > > They also say that Fedora is targeted to end users due its life cycle,
> > but
> > > many people is using Fedora for servers/desktops in the enterprise, like
> > me.
> >
> > I think Fedora is a good choice for desktop users if you don't mind
> > upgrading every year or when they drop support for that version. ( I
> > use Fedora at home, work and on my laptop.  If you wanted a longer
> > life cycle and or more stable choice move over to CentOS which has the
> > same documentation as RHEL and same life cycle.  I don't think this
> > would have fizzled down to RHEL and CentOS as it was with Fedora 12.
>
>
>
> I completely agree. I never wanted Fedora for a server environment because
> it is a
> desktop distribution and a test environment for RHEL.   I believe that
> CentOS is the
> right choice because it has been my distribution for many years but ...
> sometimes
> you have no choice ;)
>
> Regards,
>
> Xavier Garcia
>
>
>
>
> > Regards,
> >
> > -mmiller
> >
> > > 2009/11/19 Michael Miller <mike.mikemiller at gmail.com>
> > > > I think the idea is to provide the same type of control that you have
> > > > with Active Directory and GPO software polices.  Which are based on
> > > > HASH values or Certificates rolled out by GPO.  I don't think the
> > > > developers where looking at it from the same view point of system
> > > > administrators.  Who most likely are going to be in a corporate
> > > > environment. They want software (installs)  to be easy for people
> > > > switching over from Windows.
> > > >
> > > > I say that based on what one of the mission statements ( with a lot of
> > > > paraphrasing on my part. ) from Fedora Project.  I think if you where
> > > > to role this out in a corporate environment this would work out really
> > > > well.  If one was to do it correctly and maintain their own software
> > > > repositories.  Which would decrease the number of help desk calls when
> > > > a user needed some software installed to do there job.
> > > >
> > > > <Personal Opinion>
> > > > I have the view point that if have a based image ( Stripped down OS )
> > > > you reduce security issues because you don't have Acrobat or Flash
> > > > installed on 500 machines in your environment.  You only have Acrobat
> > > > or flash installed on the machines of the people who need to use that
> > > > software.  In a perfect world that would be 10 or 15 people.   Which
> > > > is a different line of thinking from most Microsoft shops where they
> > > > want every machine to be exactly the same to reduce software
> > > > conflicts.
> > > > </Personal Opinion>
> > > >
> > > > Sorry for the rant.
> > > >
> > > > mmiller
> > > >
> > > > On Thu, Nov 19, 2009 at 1:57 AM, Xavier Garcia <xavi.garcia at gmail.com>
> > > > wrote:
> > > > > Hi guys,
> > > > >
> > > > > First, sorry for my broken english.
> > > > >
> > > > >
> > > > > This is from Dailydave. Have a look at this bug report from RedHat
> > > > > (Fedora12). Hilarious!
> > > > >
> > > > > https://bugzilla.redhat.com/show_bug.cgi?id=534047
> > > > >
> > > > > "Bug 534047 -  All users get to install software on a machine they do
> > > > > not have the root password to"
> > > > >
> > > > > All these years working to have a standard and controlled
> > environment.
> > > > > Now all this is bs and everybody
> > > > > should be able to install whatever they want in a desktop environment
> > > > > because the packages are signed and are trusted (secure).
> > > > >
> > > > >
> > > > > "PackageKit allows you to install signed content from signed
> > > > > repositories
> > > > > without a password by default. It only asks you to authenticate if
> > > > > anything is
> > > > > unsigned or the signatures are wrong. "
> > > > >
> > > > > Fail!
> > > > >
> > > > > Regards,
> > > > >
> > > > > Xavier Garcia
> > > > > _______________________________________________
> > > > > Pauldotcom mailing list
> > > > > Pauldotcom at mail.pauldotcom.com
> > > > > http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom
> > > > > Main Web Site: http://pauldotcom.com
> > > > _______________________________________________
> > > > Pauldotcom mailing list
> > > > Pauldotcom at mail.pauldotcom.com
> > > > http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom
> > > > Main Web Site: http://pauldotcom.com
> > >
> > >
> > > _______________________________________________
> > > Pauldotcom mailing list
> > > Pauldotcom at mail.pauldotcom.com
> > > http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom
> > > Main Web Site: http://pauldotcom.com
> > _______________________________________________
> > Pauldotcom mailing list
> > Pauldotcom at mail.pauldotcom.com
> > http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom
> > Main Web Site: http://pauldotcom.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.pauldotcom.com/pipermail/pauldotcom/attachments/20091121/6b47bff3/attachment.htm