Hi all.

I've Googled for the last 2 hours looking for the default set of packages installed by Red Hat 7 when the Server role is selected, but have so far come up empty. I was naive enough to think that this sort of thing might be documented by Redhat somewhere on their website! Not!

What I'm looking for is a list of default packages installed when I opt to set the machine up as a server without selecting anything else. I know I could just as easily wipe the system clean and do a test installation and run rpm -qa, but that is not an option at the moment. However, if no one has documented this before, it might be time to make it an option.

Cheers,
tkb.

This is because RedHat no longer support RH7,8 or 9. So, naturally there is no information.

In RH8 or 9, anaconda will give you the information you are looking for. Dunno about RH7. Strongly suggest a more recent distribution.

Meanwhile - you can check by looking for all files called *.rpm.

http://leda.law.harvard.edu/leda/man...ll/pkglist.htm
packages in the RH7 base install for the LEDA server.

http://www.linuxcdmall.com/redhat.html
gives complete package lists for RH8 and RH9 - but dosn't distinguish the different install modes.

Simon, thanks for your help/suggestions.

Where did you get that list from? If Google, then I'll have to raise issues with them as to why my searches are yielding zilch!

My problem is that I am responsible for several Redhat 7 servers that were deployed a while back (think 8 years ago) and now due to the Enron debacle, SoX and Trust Domain audits are getting me down.

When these machines were first installed, the Server role was selected and nothing else was added/removed. To satisfiy SoX TD, I need to know the basic packages so that we can then audit these machines and determine what additional software has been added/removed. This is my dilemma.

Looks like the moment has come to buy some hardware that is similar to what is currently deployed and install RH7 to verify.

One last question - will running rpm -qa give a definite answer as to what was just installed? In other words, has it been known to spew false information - such as not listing all installed packages or worse still, listing some that were not actually installed?

Cheers,
tkb.

Where did you get that list from? If Google, then I'll have to raise issues with them as to why my searches are yielding zilch!

Google search term: redhat 7 package list
The LEDA site is the third from the top. To be fair - google have got a lot of information about me and my search habits.

My problem is that I am responsible for several Redhat 7 servers that were deployed a while back (think 8 years ago)

<shakes head> were these old redhat servers robust or what? RH7 was the first linux I experienced ... running MSOffice and MatLab under Win4Lin. A couple-score of these were installed to the Physics Dept network at Auckland University by an old Windows admin.

Looks like the moment has come to buy some hardware that is similar to what is currently deployed and install RH7 to verify.

Yup. That would provide a baseline for the audit. Sounds like a thankless job - hope you're getting paid.

In fact - as a first estimate, I'd ahve installed to J Random Box and had a look.

One last question - will running rpm -qa give a definite answer as to what was just installed? In other words, has it been known to spew false information - such as not listing all installed packages or worse still, listing some that were not actually installed?

I think the rpm headers (or something) have to be present. However - removing the information about any package installed via rpm or up2date in the servers lifetime would require a deliberate effort. It would not report, of course, anything installed from source.

Are you anticipating that someone has been maliciously fiddling?

No, no. We are not worried that someone has fiddled with the machine maliciously in the past, but it is a SoX requirement to be able to tell if/when such a deed has occurs in the future. In fact, the guys doing the SoX audit want the system to report to a designated big brother whenever root logs in for whatever reason!

Leads me to yet another question - is there a way to limit what a user can do with sudo? For instance, is it possible to limit the scope of commands? For example, I want the users in the sudoers file to be able to use commands such as rm and rmdir in certain areas of the file system (such as /tmp), but not others (such as /var/log) - is this possible?

Cheers,
tkb.

You can specify arguments to commands in /etc/sudoers, e.g.

or something along those lines. You can use '!...' to disallow a command (e.g. '!/bin/rm /var/log/*'), but the user wouldn't be able to delete files in /var/log anyway unless it is specifically allowed.

You guys are the best.

As you can see, I joined LinuxQuestions quite a while back but have not been very vocal in the forums as I only fiddled with Redhat Linux 5.2/6.x (got it off a magazine) for a while then stopped using it. However, I'm now taking it up whole heartedly as I venture into MythTV and other really cool things that are Linux (not to mention that at my work place Linux is extensively used) and have become quite savvy with the CLI. 'Nough said.

I'm now heading to RTFM and explore everything that I can do with that sudoers file.

Cheers,
tkb.

Oh yes, I forgot to mention that tags are a really nice feature. If only everyone can start using them...

Cheers,
tkb.

FYI, as mentioned, those are no longer supported, so for security's sake see if you can upgrade/replace with current versions. As a by-product, you'll also be sure exactly what's on them...