On Thu, Nov 18, 2010 at 12:54:05PM -0500, lcf004 wrote:
> Barry Brimer wrote:
> >Red Hat does provide a boot iso in RHN. For (32-bit x86) servers it is
> >called
> >rhel-server-6.0-i386-boot.iso and for (32-bit x86) workstations it is
> >called
> >rhel-workstation-6.0-i386-boot.iso. Are you getting your media from RHN or
> >another source?
>
> I get it straight from RHN. I find it hard to believe that I have
> access to all the installation media they have to offer all the way back
> to RedHat 9 on every platform but I am not allowed to have the boot.iso.
> However, it is _not_ there. If someone can actually see it, please
> post a link to the RHN page and maybe I can get at it that way?
>
> > Installation numbers appeared in RHEL 5 and was used to
> >configure the installer to allow you to use the packages you were licensed
> >to
> >use. RHEL 3 and 4 didn't have this because they were packaged/sold
> >separately.
> > RHEL 2.1 included the license for it but was installed separately. In
> > RHEL 6
> >these are add-ons. I doubt it makes sense to have an installation number
> >for
> >RHEL,
>
> I need to my new vendor supplied licenses are added into my volume
> licensing via RHN. Since I installed RHEL 6 instead of 5, they aren't
> registered, they don't show up under my licensing info for the
> university and there is no way via RHN's website to get them in there.
>
> and Resilient Storage and Load Balancing, etc. Forced TLS on LDAP while
> >it may differ from previous releases is a best practice. Sending
> >unencrypted
> >credentials across the network is not a good idea. I've never had a
> >problem
> >with installing software I need to use, and ksh is no exception.
> >
>
> The problem in a nutshell is this, and I am sure I am no real exception
> here: I have long time developed post installation packages, scripts
> and programs that set things up in standard ways to make RHEL
> installations here usable for a standard subset of users. This new
> release takes great pains to break what I (at least) thought was a very
> well thought out standard set of packages and services that RHEL 5
> provided. At this point I am still finding things that are missing and
> broken as I plow through all this and the impression I am getting is
> that for an enterprise ready release, it's not very enterprise ready.
> For instance, people who do large volume server installs don't have time
> to use the GUI tools to configure their LDAP authentication,
> notwithstanding having to crawl around looking for why you can't auth
> the way you need to. I am not opposed to installing packages either,
> but there are some that certainly make sense to already be there that
> just aren't, not that ksh necessarily is one of them, but pam_ldap sure
> is and there are others I keep finding as well.
>
> --
> Lincoln Fessenden
As for other things changed, as far as I can recall, this issue (below)
did not occur in RHEL5 or earlier...
My employer sells a product that is compiled for RHEL (currently 4, 5, and
soon to be 6), that requires uudecode at install-time. In past versions we
always found it in the sharutils package.
well, in RHEL6 it's still in sharutils, HOWEVER, sharutils is now in the
"optional" repository, no longer in the default repo, and as far as I
can figure out (by looking at the beta,... I haven't yet had a chance
to inspect the final release) sharutils is also NOT on the installation
media.
So, before our product can be installed, someone needs to go find the
optional repository and install the sharutils package.
Not what we had hoped for!
Fred
--
---- Fred Smith -- fredex@xxxxxxxxxxxxxxxxxxxxxx -----------------------------
I can do all things through Christ
who strengthens me.
------------------------------ Philippians 4:13 -------------------------------
--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
