----- Original Message ----- | This is a continuation of the thread about redhat vs centos and the | thought of moving from centos | due to redhats new business model. Forgive the length, but I had to | share. | | I went ahead and downloaded the 5 year supported version of ubuntu | server. | You think centos/redhat is a bit tough or not polished? | One day with ubuntu server and you will look at centos install and | setup | as a god! Let me start out by saying that I totally agree with you here. Ubiquity is a really crappy installer! I've fought with it for many years. However, like RHEL/CentOS you can use kickstart to install the machine. It's called kickseed in Ubuntu/Debian and maps a subset of the Kickstart features to the debian-installer equivalent. | Where do I begin? | | 1- you download the iso, burn a cd. But guess what? It is only a small | boot setup (about 600mb). | The install actually sets up your eth port and then SLOWLY downloads a | base set of packages. This, like the RHEL/CentOS installer can be changed if you are using kickstart. If you are are installing from CD it will install packages *that have not been updated* from the CD. However, the installer does check security.ubuntu.com and downloads updates during installation for those packages. This would be the equivalent to including the updates and CR repos during a kickstart. | Then when you are done with your drive set up, you get to pick a | package. | Then it downloads and installs, asking you a few questions as it does. | Then it upgrades itself. | About 40 minutes due to the downloads for me... See above statement. If you are kickstarting, it's no big deal. | 2- uses a really lame 1980 DOS version of a text installer. It does | not | and will not use a basic vid driver install | which means your setting up of lvms and such during the install is | really fun. Then you downloaded the alternative, netboot or server installer. The desktop installer is fully graphical, however, is lacking many features such as LVM and RAID support selections. This is *entirely* different than Anaconda which actually works the same whether using the text, VNC or standard graphical install. | 3- I don't know about having a server being forced to connect to the | internet before you can even begin to secure | it up. But the only way to really install it is to do that. Wait til | you | see the insecure firewall setup if gave me too.. And during installation of RHEL/CentOS how to do secure the box before installing? How about applying updates before putting it in production? Let's be fair here. | 4- I picked the virtual host package, as the machine will hold guest | OS's (presumably ubuntu). Would be covered by a kickstart and a virtual host package is the equivalent to the package group in RH speak | 5- booted up fine. | | 6- uses upstart and init, mixed up a bit. Upstart, BY DESIGN AND | ACCORDING TO DOCUMENTATION is new and | still being built so they do not want to put any documentation out on | it | yet. This makes chkconfig and things like | that useless. Hence, if you want to know what is running, set to run, | etc, you need to dig in multiple folders and | read the scripts. There is no other way. What a horror. You are arguing that something is misunderstood by you and thereby horrific. As a person who manages several UNIX & UNIX-like operating systems, I would agree that it is "horrific" to have to understand the differences about how to enable / disable services on each platform. | 7- The install, of the virtual host, added libvirt. It did not however | install things like virt-install or any other virt software. | Infact, no guest installation tools were added, though things like | virsh | were installed. Sigh. That is correct, those packages are provided as "extra" tools. They are not needed for virtualization to work. | | 8- The firewall and network do not have the scripts folder. You have | to | build your own firewall file and add scripts | to make it over ride the stock one via the eth you want to use it | for....wtf? Is it that you don't understand where they are or that it's just not possible? There's a difference. Yeah, on RH there is an /etc/sysconfig/network-scripts. On Debian/Ubuntu there is a /etc/network/interfaces file that controls all. What's wrong with that. Personally, I can think of lots of things, but it's my opinion. I'm trying to show that you are making assumptions about how this "should" be compared to how things are before learning the "why" things are the way they are. | 9- here is the firewall, for a virtual host, that should not have | anything but port 22 open as far as the initial install | should (at least in my opinion).....Ubuntu starts with this.... | (remember, ubuntu forces you to be online to install and this is how | it | protects your server) | | I was not blocked on a single port going from my desktop to my server | via my router. ALL PORTS were accessible. | This is out of the box. Shell 22 was open from all my computers. Not | listed in the firewall as open. | You can see it is quite different than the centos stock and I think | ubuntu is a 'run away' install. It is? SSH is open in all stock installs. | There is no bridge set up in the network interface files either. There | is no bridge set up. Yes, but you installed the virtualization package group which set this up for you. The fact that it isn't there is irrelevant. If you added it you would be protected. | The firewall is looking at virbr0 but there is no such configuration I | could find in the | etc folder, anywhere. | Very odd. | | # Generated by iptables-save v1.4.4 on Mon Nov 7 23:35:47 2011 | *nat | :PREROUTING ACCEPT [84:12492] | :POSTROUTING ACCEPT [9:626] | :OUTPUT ACCEPT [9:626] | -A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p tcp -j | MASQUERADE --to-ports 1024-65535 | -A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p udp -j | MASQUERADE --to-ports 1024-65535 | -A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -j MASQUERADE | COMMIT | # Completed on Mon Nov 7 23:35:47 2011 | # Generated by iptables-save v1.4.4 on Mon Nov 7 23:35:47 2011 | *filter | :INPUT ACCEPT [3701:295955] | :FORWARD ACCEPT [0:0] | :OUTPUT ACCEPT [793:1276008] | -A INPUT -i virbr0 -p udp -m udp --dport 53 -j ACCEPT | -A INPUT -i virbr0 -p tcp -m tcp --dport 53 -j ACCEPT | -A INPUT -i virbr0 -p udp -m udp --dport 67 -j ACCEPT | -A INPUT -i virbr0 -p tcp -m tcp --dport 67 -j ACCEPT | -A FORWARD -d 192.168.122.0/24 -o virbr0 -m state --state | RELATED,ESTABLISHED -j ACCEPT | -A FORWARD -s 192.168.122.0/24 -i virbr0 -j ACCEPT | -A FORWARD -i virbr0 -o virbr0 -j ACCEPT | -A FORWARD -o virbr0 -j REJECT --reject-with icmp-port-unreachable | -A FORWARD -i virbr0 -j REJECT --reject-with icmp-port-unreachable | COMMIT | # Completed on Mon Nov 7 23:35:47 2011 | | | In closing, it is down to suse or back to centos and just pray redhat | turns around. Maybe scientific linux. | Ubuntu is not ready for prime time and a HUGE step backwards. It is | not | cutting edge and very insecure. | | So maybe centos, even if a year or two behind, is way better than | ubuntu | will ever be. | | | I took a shot at paid support. | You have to send them a contact mail. I did. | After 3 days sent them another. | 2 days later, no response from that one either. | | down to suse or back to centos. | | One good thing about ubuntu was the bug redhat has for the ati onboard | video is not an issue making | no errors on boot and no long hang time that centos was causing me. I can't believe that I have defended Ubuntu so much in this E-Mail. I don't even like Ubuntu! I used it for years, but only as a personal desktop and from that perspective it was a *really* nice platform to work with. It made installing proprietary drivers and codecs a snap (thereby signing off all my freedoms ;) ), but if you need to deviate from the "Ubuntu way" or do *anything* that is remotely complex Ubuntu falls over dead and this is why I moved away from it. There was some talk about porting Anaconda to Ubuntu to replace Ubiquity. I'd welcome that and maybe even start to use it in our department, but there are still *way* too many "broken" things that stop me from rolling it out. One of those things just happens to be the insatiable need to just rip out core parts of the system willy-nilly to get the lasted "cool kid" code. -- James A. Peltier IT Services - Research Computing Group Simon Fraser University - Burnaby Campus Phone : 778-782-6573 Fax : 778-782-3045 E-Mail : jpeltier at sfu.ca Website : http://www.sfu.ca/itservices http://blogs.sfu.ca/people/jpeltier I will do the best I can with the talent I have