Puppet sounds perfect for what you're trying to do, with the caveat that as of right now, there is no support for Windows.
In your case, you would define a Server node in terms of all of the packages that are identical across the machines. Then, you define the individual hosts as nodes which inherit from Server, and set up the specific unique things for it.
Puppet is declarative - it allows you to describe of your boxes in terms of the resources each box should have. So if you want ssh - you write a class for that resource - and inside the class you can include logic about how ssh is called slightly different on FreeBSD vs Ubuntu. It also knows to use yum inside Redhat and apt-get inside Debian based distros, and ports in the BSDs. Now in your Server node, you'll just have a line like include ssh - and puppet will do the right thing and put SSH on the machine without you having to remember if that's Ubuntu or Redhat or FreeBSD.
What's nice is that all of the Server stuff lives in one place - and if at any point you add to the Server node definition, ALL machines would update their configuration accordingly.
Right now, I'm only managing three boxes using Puppet - but it's already paid off. After spending a week setting up a box we'll be using for stimulus presentation in an experiment, it turned out the graphics card driver was too old in the version of Ubuntu I put on it (8.04). I had to install the latest Ubuntu (9.04), but after that I just had to apt-get and run puppet - and everything I had spent a week setting up was restored.
Puppet does have a little bit of a learning curve, but I've successfully avoided learning Ruby - I know I'm using it, since that's what puppet is written in - but so far I've been successful in just modifying the examples in the documentation and the recipes on the wiki . Another downside is that puppet does take a bit longer to do things the first time. The upside is that everything you change across all of your machines is stored in one place - it's standard practice to keep your puppet configuration in a version control system - so you can always look back and see how you've set up servers in the past - or roll-back some unsuccessful changes.
Finally, here's a quick video that does a simple puppet demo that got me
started quickly.
Short answer: you can't. Ports below 1024 can be opened only by root. As per comment - well, you can, using CAP_NET_BIND_SERVICE, but that approach, applied to java bin will make any java program to be run with this setting, which is undesirable, if not a security risk.
The long answer: you can redirect connections on port 80 to some other port you can open as normal user.
Run as root:
# iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080
As loopback devices (like localhost) do not use the prerouting rules, if you need to use localhost, etc., add this rule as well (thanks @Francesco):
# iptables -t nat -I OUTPUT -p tcp -d 127.0.0.1 --dport 80 -j REDIRECT --to-ports 8080
NOTE: The above solution is not well suited for multi-user systems, as any user can open port 8080 (or any other high port you decide to use), thus intercepting the traffic. (Credits to CesarB).
EDIT: as per comment question - to delete the above rule:
# iptables -t nat --line-numbers -n -L
This will output something like:
Chain PREROUTING (policy ACCEPT)
num target prot opt source destination
1 REDIRECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:8080 redir ports 8088
2 REDIRECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 redir ports 8080
The rule you are interested in is nr. 2, so to delete it:
# iptables -t nat -D PREROUTING 2
Best Answer
The ULN tools
uln_registerandulnreg_ksare only symlinks to original RHN toolsrhn_registerandrhnreg_ksso they may be used the same way. The main change compared to original RHN is in/etc/sysconfig/rhn/up2dateconfiguration file where it is defined Oracle ULN server. The first one provides interactive TUI interface while the second one is noninteractive.So the answer is to use this simple command (man rhnreg_ks)