Generate Certificate Signing Request on Linux

You create a CSR and have it signed by a CA before you can use a certificate. This tutorial is a continuation from my tutorial on creating a CA. However, you do not need to create a CA to generate a CSR.

Install Prerequisites

I wrote this tutorial using Fedora 18. The only prerequisite I needed was OpenSSL.

su -c 'yum install openssl'

Create Directory Structure

mkdir /home/cg/mycert

cd /home/cg/mycert/

mkdir private conf csr

We will run all commands by default in the /home/cg/mycert directory, unless stated otherwise.

Config File

vim /home/cg/mycert/conf/serverconfig.cnf

This file would serve as the config file if you wish to use it. An example file is below.

[ ca ]
default_ca = CA_default

[ CA_default ]
dir = /home/cg/mycert/
certs = $dir/certs
crl_dir = $dir/crl
database = $dir/index.txt
new_certs_dir = $dir/newcerts
certificate = $dir/certs/cacert.pem
serial = $dir/serial
#crl = $dir/crl.pem
private_key = $dir/private/cakey.pem
#RANDFILE = $dir/private/.rand
x509_extensions = usr_cert
#crl_extensions = crl_ext
default_days = 3650
#default_startdate = YYMMDDHHMMSSZ
#default_enddate = YYMMDDHHMMSSZ
#default_crl_days= 30
#default_crl_hours = 24
default_md = sha1
preserve = no
#msie_hack
policy = policy_match

[ policy_match ]
countryName = match
stateOrProvinceName = match
localityName = match
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = optional

[ req ]
default_bits = 4096 # Size of keys
default_keyfile = key.pem # name of generated keys
distinguished_name = req_distinguished_name
attributes = req_attributes
x509_extensions = v3_ca
#input_password
#output_password
string_mask = nombstr # permitted characters
req_extensions = v3_req

[ req_distinguished_name ]
countryName = Country Name (2 letter code)
countryName_default = US
countryName_min = 2
countryName_max = 2
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = New York
localityName = Locality Name (city, district)
localityName_default = New York
organizationName = Organization Name (company)
organizationName_default = Code Ghar
organizationalUnitName = Organizational Unit Name (department, division)
organizationalUnitName_default = IT
commonName = Common Name (hostname, FQDN, IP, or your name)
commonName_max = 64
commonName_default = CGIT
emailAddress = Email Address
emailAddress_max = 40
emailAddress_default = codeghar@example.com

[ req_attributes ]
#challengePassword = A challenege password
#challengePassword_min = 4
#challengePassword_max = 20
#unstructuredName = An optional company name

[ usr_cert ]
basicConstraints= CA:FALSE
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer:always
#nsComment = ''OpenSSL Generated Certificate''
#nsCertType = client, email, objsign for ''everything including object signing''
subjectAltName=email:copy
issuerAltName=issuer:copy
#nsCaRevocationUrl = http://www.domain.dom/ca-crl.pem
#nsBaseUrl = 
#nsRenewalUrl =
#nsCaPolicyUrl = 
#nsSslServerName =

[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment

[ v3_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer:always
basicConstraints = CA:TRUE
#keyUsage = cRLSign, keyCertSign
#nsCertType = sslCA, emailCA
#subjectAltName=email:copy
#issuerAltName=issuer:copy
#obj=DER:02:03

[ crl_ext ]
#issuerAltName=issuer:copy
authorityKeyIdentifier=keyid:always,issuer:always

Generate CSR

You can use the config file (serverconfig.cnf) we created in the previous step to answer a lot of the questions asked during certificate generation. Just run the following command and answer the questions. Most questions will have the default values provided in serverconfig.cnf.

openssl req -new -config conf/serverconfig.cnf -keyform PEM -keyout private/key.csr.server1.pem -outform PEM -out csr/csr.server1.pem -nodes

If you want to provide your own custom values you may run the following command instead.

openssl req -new -newkey rsa:4096 -keyform PEM -keyout private/key.csr.server1.pem -outform PEM -out csr/csr.server1.pem -nodes

You will be asked relevant questions. Following is an example output of the process.

Generating a 4096 bit RSA private key
..............................................................................++
.................++
writing new private key to 'private/key.csr.server1.pem'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [US]:
State or Province Name (full name) [New York]:
Locality Name (city, district) [New York]:
Organization Name (company) [Code Ghar]:
Organizational Unit Name (department, division) [IT]:
Common Name (hostname, FQDN, IP, or your name) [CGIT]:
Email Address [codeghar@example.com]:server1@example.com

Two files, key.csr.server1.pem and csr.server1.pem, will be created in $dir/private and $dir/csr directories respectively. Keep these files in a safe location and back them up.

You will submit csr.server1.pem to the CA who will sign it. The CA will sign the file and return the resulting file to you. That will be the certificate you will finally use.

Advertisements

Create Private Certificate Authority on Linux

This tutorial will show you how to create your own private CA or Certificate Authority. This will give you the opportunity to sign your own certificates without having to pay someone else. However, since your private CA will not be trusted by others it may prompt warnings when others use it. You will need to add your root certificate to the machines you want to trust your CA.

I had written a similar article in 2008 (Create a Certificate Authority and Certificates with OpenSSL) but this tutorial supersedes the instructions for creating CA in the older one.

Install Prerequisites

I wrote this tutorial using Fedora 18. The only prerequisite I needed was OpenSSL.

su -c 'yum install openssl'

Create Directory Structure

mkdir /home/cg/myca

cd /home/cg/myca/

mkdir private certs newcerts conf export csr

echo '01' > serial

touch index.txt

We will run all commands by default in the /home/cg/myca directory, unless stated otherwise.

Config File

vim /home/cg/myca/conf/caconfig.cnf

This file would serve as the default config file for the CA. It should look something like the following:

[ ca ]
default_ca = CA_default

[ CA_default ]
dir = /home/cg/myca/
certs = $dir/certs
crl_dir = $dir/crl
database = $dir/index.txt
new_certs_dir = $dir/newcerts
certificate = $dir/certs/cacert.pem
serial = $dir/serial
#crl = $dir/crl.pem
private_key = $dir/private/cakey.pem
#RANDFILE = $dir/private/.rand
x509_extensions = usr_cert
#crl_extensions = crl_ext
default_days = 3650
#default_startdate = YYMMDDHHMMSSZ
#default_enddate = YYMMDDHHMMSSZ
#default_crl_days= 30
#default_crl_hours = 24
default_md = sha1
preserve = no
#msie_hack
policy = policy_match

[ policy_match ]
countryName = match
stateOrProvinceName = match
localityName = match
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = optional

[ req ]
default_bits = 4096 # Size of keys
default_keyfile = key.pem # name of generated keys
distinguished_name = req_distinguished_name
attributes = req_attributes
x509_extensions = v3_ca
#input_password
#output_password
string_mask = nombstr # permitted characters
req_extensions = v3_req

[ req_distinguished_name ]
countryName = Country Name (2 letter code)
countryName_default = US
countryName_min = 2
countryName_max = 2
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = New York
localityName = Locality Name (city, district)
localityName_default = New York
organizationName = Organization Name (company)
organizationName_default = Code Ghar
organizationalUnitName = Organizational Unit Name (department, division)
organizationalUnitName_default = IT
commonName = Common Name (hostname, FQDN, IP, or your name)
commonName_max = 64
commonName_default = CGIT
emailAddress = Email Address
emailAddress_max = 40
emailAddress_default = codeghar@example.com

[ req_attributes ]
#challengePassword = A challenege password
#challengePassword_min = 4
#challengePassword_max = 20
#unstructuredName = An optional company name

[ usr_cert ]
basicConstraints= CA:FALSE
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer:always
#nsComment = ''OpenSSL Generated Certificate''
#nsCertType = client, email, objsign for ''everything including object signing''
subjectAltName=email:copy
issuerAltName=issuer:copy
#nsCaRevocationUrl = http://www.domain.dom/ca-crl.pem
#nsBaseUrl = 
#nsRenewalUrl =
#nsCaPolicyUrl = 
#nsSslServerName =

[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment

[ v3_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer:always
basicConstraints = CA:TRUE
#keyUsage = cRLSign, keyCertSign
#nsCertType = sslCA, emailCA
#subjectAltName=email:copy
#issuerAltName=issuer:copy
#obj=DER:02:03

[ crl_ext ]
#issuerAltName=issuer:copy
authorityKeyIdentifier=keyid:always,issuer:always

Thanks to http://wwwneu.secit.at/web/documentation/openssl/openssl_cnf.html for helping with this file.

Generate Root Certificate

You can use the config file (caconfig.cnf) we created in the previous step to answer a lot of the questions asked during certificate generation. Just run the following command and answer the questions. Most questions will have the default values provided in caconfig.cnf.

openssl req -new -x509 -days 3650 -config conf/caconfig.cnf -keyform PEM -keyout private/key.ca.cg.pem -outform PEM -out certs/crt.ca.cg.pem

Although we specified the default number of days in caconfig.cnf file, we still have to specify the days flag when using the x509 flag. If we don’t the certificate is created with a default value of 30 days. Thanks to Re: default_days problem and OpenSSL req(1).

If you want to provide your own custom values you may run the following command instead.

openssl req -new -x509 -days 3650 -newkey rsa:4096 -extensions v3_ca -keyform PEM -keyout private/key.ca.cg.pem -outform PEM -out certs/crt.ca.cg.pem

You will be asked for a passphrase. Make sure you use a secure passphrase and don’t forget it. You will also be asked other relevant questions. Following is an example output of the process.

Generating a 4096 bit RSA private key
..............................................................................++
...........................................................................................................................................................................................................................................++
writing new private key to 'private/key.ca.cg.pem'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [US]:
State or Province Name (full name) [New York]:
Locality Name (city, district) [New York]:
Organization Name (company) [Code Ghar]:
Organizational Unit Name (department, division) [IT]:
Common Name (hostname, FQDN, IP, or your name) [CGIT]:
Email Address [codeghar@example.com]:

Two files, key.ca.cg.pem and crt.ca.cg.pem, will be created in $dir/private and $dir/certs directories respectively. Make sure you keep these files in a secure place and make their backups.

crt.ca.cg.pem is your root certificate and will be used to sign all the other certificates.

Verify Root Certificate

You should verify that the certificate was created properly with accurate information.

openssl x509 -in certs/crt.ca.cg.pem -inform pem -noout -text

Export Root Certificate

Since this newly created CA and its root certificate are not recognized and trusted by any computer, you need to import the root certificate on all other computers. By default an OS will have a list of trusted CAs and you need to import your CA to that list. The process varies for different OSes.

Windows

The root certificate we created is in PEM encoded format. For Windows we need it to be in DER encoded format. A great resource on the differences between the two is DER vs. CRT vs. CER vs. PEM Certificates and How To Convert Them.

openssl x509 -in certs/crt.ca.cg.pem -outform der -out export/ca.cg.crt

Verify the certificate was created successfully.

openssl x509 -in export/ca.cg.crt -inform der -noout -text

Once you have the exported file, copy it to your Windows machine. You can follow the instructions provided by How To Import a Trusted Root Certification Authority In Windows to import the certificate to the Trusted Root Certification Authorities store on Local Computer.

You can also export the certificate to PKCS12 format. Thanks to Importing a User Certificate to the Windows Certificate Store for this information.

openssl pkcs12 -export -out export/ca.cg.p12 -in certs/crt.ca.cg.pem -inkey private/key.ca.cg.pem

You will be asked to provide the passphrase you used to create the root certificate. You will also be asked for a new “Export Password”.

Copy the .p12 file to Windows and double-click it. A wizard will open and guide you to install it.

Conclusion

The process to create a CA is very simple. Next I will write about signing a certificate request.

Further Reading

Create Network PXE Boot Server with Fedora 18

Special thanks to Manually configure a PXE server, from Fedora’s documentation, for providing very useful information. You should consider that documentation as much more authoritative than this post. I have tried to focus on setting up infrastructure for multiple distros, BIOS, and IPv4. I’ll update with IPv6 and EFI as I test that.

Disclaimer: Although I have tested this post it may still be incomplete or may contain errors.

Installing an OS over the network is a big time saver, especially when combined with autoconfig options such as Kickstart, Pressed, and AutoYaST. The first step in doing so is create the infrastructure that allows a computer or server to boot from the network and install the OS. These instructions were created using Fedora 18. Install it in a VM and you are good to go. Make sure it uses static IPv4 and IPv6 addresses and is accessible via SSH.

The network boot server used for these instructions was named noosa. Whenever noosa is mentioned in these instructions understand that it refers to the boot server. Let’s say noosa has an IPv4 address of 192.168.1.15 and IPv6 address of 2100:192:168:1::15. Create a user called idopxe on the server, used later in the instructions.

You’ll need a DHCP server running on this server. This could cause conflicts on your network if you’re already running a DHCP server. But if your current DHCP server supports the extra options mentioned in these instructions then you can continue to use it. Otherwise you may have to replace your current DHCP server with the one running on noosa.

Major steps in the process are:

  • Install and Configure TFTP Server
  • Create PXE Directory Structure
  • Copy OS ISOs to Boot Server
  • Extract Files from OS ISO
  • Configure PXE
  • Install and Configure HTTP Server
  • Install and Configure DHCP Server

Install and Configure TFTP Server

su -c 'yum install tftp-server'

Enable the service by editing the file /etc/xinetd.d/tftp and change

disable = yes

to

disable = no

Start the TFTP server. You’re starting xinetd because TFTP server is a xinetd-based service.

su -c 'systemctl start xinetd.service'

su -c 'systemctl enable xinetd.service'

You can now place files in /var/lib/tftpboot/ to be served by TFTP.

Create PXE Directory Structure

cd /var/lib/tftpboot/

su -c 'mkdir loopdir'

su -c 'mkdir linux'

su -c 'mkdir linux/fedora'

su -c 'mkdir linux/fedora/18'

su -c 'mkdir linux/fedora/18/x86_64'

su -c 'mkdir linux/fedora/18/x86_64/dvd'

su -c 'mkdir linux/fedora/18/x86_64/dvd/iso'

su -c 'mkdir linux/fedora/18/x86_64/dvd/files'

su -c 'mkdir linux/fedora/18/x86_64/dvd/kickstart'

Copy/download/upload Fedora 18 64-bit DVD ISO to /var/lib/tftpboot/linux/fedora/18/x86_64/dvd/iso/ directory.

Extract Files from OS ISO

su -c 'mount -o loop /var/lib/tftpboot/linux/fedora/18/x86_64/dvd/iso/Fedora-18-x86_64-DVD.iso /var/lib/tftpboot/loopdir'

rsync -v -a -H --exclude=TRANS.TBL /var/lib/tftpboot/loopdir/ /var/lib/tftpboot/linux/fedora/18/x86_64/dvd/files/

su -c 'umount /var/lib/tftpboot/loopdir'

Configure PXE

cd /var/lib/tftpboot/

su -c 'vim defaultbootmenu.txt'

Make sure it has the following contents:



== BOOT MENU ==

localdisk
fedora_18_dvd_64_bios_default
fedora_18_dvd_64_efi_default
fedora_18_dvd_64_bios_kickstart
fedora_18_dvd_64_efi_kickstart


Create a new directory:

su -c 'mkdir pxelinux.cfg'

cd pxelinux.cfg

su -c 'vim default'

DISPLAY defaultbootmenu.txt

DEFAULT localdisk

LABEL localdisk
    localboot 0x80

LABEL fedora_18_dvd_64_bios_default
    kernel linux/fedora/18/x86_64/dvd/files/isolinux/vmlinuz
    append initrd=linux/fedora/18/x86_64/dvd/files/isolinux/initrd.img repo=http://192.168.1.15/repo/linux/fedora/18/x86_64/dvd/files/

LABEL fedora_18_dvd_64_bios_kickstart
    kernel linux/fedora/18/x86_64/dvd/files/isolinux/vmlinuz
    append initrd=linux/fedora/18/x86_64/dvd/files/isolinux/initrd.img ks=http://192.168.1.15/repo/linux/fedora/18/x86_64/dvd/kickstart/anaconda-ks.cfg

implicit        1
prompt          1
timeout         300


You’ll need to install the SYSLINUX package.

su -c 'yum install syslinux'

Copy pxelinux.0 file from SYSLINUX to tftpboot directory.

cp /usr/share/syslinux/pxelinux.0 /var/lib/tftpboot/

Install and Configure HTTP Server

su -c 'yum install httpd'

su -c 'systemctl start httpd.service'

su -c 'systemctl enable httpd.service'

Remember to open ports in the firewall.

cd /var/www/html

su -c 'mkdir repo'

cd repo

su -c 'ln -s /var/lib/tftpboot/linux/ linux'

You’ll have to fix some SELinux permissions to allow httpd to be able to follow this symlink. The easiest way, if you aren’t familiar with SELinux, is to set it in permissive mode.

su -c 'setenforce 0'

Install and Configure DHCP Server

su -c 'yum install dhcp'

Edit a config file to specify on which interface to allow DHCP services to run.

su -c 'vim /etc/sysconfig/dhcpd'

Just change the value for INTERFACES in this file. In our example we want to run DHCP on eth0. So the file should have the following contents.

DHCPDARGS="eth0";

If you want to run it on multiple interfaces, for example eth0 and eth1, then it should read

DHCPDARGS="eth0 eth1";

Now edit the dhcpd.conf file.

su -c 'vim /etc/dhcp/dhcpd.conf'

ddns-update-style none;
option domain-name "codeghar.com";
option domain-name-servers 192.168.1.200, 192.168.1.201;
default-lease-time 600;
max-lease-time 7200;
log-facility local7;
class "linux-server" {
    match if substring(hardware, 1,6) = 00:11:22:33:44:55;
}
subnet 192.168.1.0 netmask 255.255.255.0 {
    pool {
        range 192.168.1.91 192.168.1.100;
        filename "pxelinux.0";
        next-server 192.168.1.15;
        option subnet-mask 255.255.255.0;
        option broadcast-address 192.168.1.255;
        option routers 192.168.1.1;
        allow members of "linux-server";
    }
}

In this configuration we give a default domain name, name servers, and other information. pxelinux.0 is the default file that other servers will use to boot when using PXE boot. next-server has the IP address of the TFTP server. In our case it’s noosa. You can use the class to match MAC addresses of certain servers only, thus not giving out dynamic IPs to other servers on your network. If your existing DHCP server can provide these options then you don’t need to run the DHCP server on noosa and instead need to pass this configuration to servers doing a PXE boot.

su -c 'systemctl start dhcpd.service'

su -c 'systemctl enable dhcpd.service'

Boot from network

Now when you boot from your target machine and choose network boot, it will get a DHCP IP and present a menu of options (defined in defaultbootmenu file). Just pick whatever is appropriate and off you go.

The New Anaconda Installer in Fedora 18

If you have tried to install Fedora 18 you’ll have seen the new Anaconda installer. Many have found major issues with its design and function. I also had some trouble with it. To learn more about it, you can watch a demo presented at FUDCon 2013: An intro to the new Fedora 18 installer (YouTube). One thing that caught my attention was that until you click “Begin Installation” no actual changes are made. Instead, as you go through the installer, steps before you click “Begin Installation” are written to a Kickstart file. This Kickstart file does the actual installation when you click “Begin Installation”.

This gives power users or those with complicated environments a big workaround to the graphical installer. You can create your own Kickstart file and just use that to complete your installation. Use the Kickstart wiki page to learn more about writing your own Kickstarts. I am playing around with a bit and it’s surprisingly easy. I’m thinking of following up with a post on how to use a Kickstart file while installing from a Fedora DVD. I’ll also try to setup a GitHub repo with various Kickstart files I create and test.

In any case, whether the graphical installer is awesome or not, having the skill to create your own Kickstart files gives you more freedom. It makes for a repeatable installation with minimal or no manual intervention. A win-win if you ask me.

Fedora: The Good, The Bad, and The Ugly

Kind of like how I did a similar post for Ubuntu I thought it might be a good idea to do one for Fedora. I like and use Ubuntu but some recent decisions by Canonical make me reconsider that loyalty. For now it’s intact though it doesn’t hurt to look at alternatives. Since I have been focusing on Fedora this year this post is relevant for others in the same situation as me.

The Good

  • Presto is the best thing in Fedora (to me at least)
  • Regular releases every six months
  • I’ll add systemd to this list because it’s not too different from using chkconfig and service and works the way it should
  • Cutting-edge technology without having to resort to rolling releases (I prefer distinct releases)
  • Unlike Canonical with Ubuntu, Red Hat doesn’t appear to have too much overt influence on the project’s direction
  • Large repository of packages, comparable to Debian and Ubuntu for packages I’m interested in
  • Better security with SELinux
  • They provide a feature list for the upcoming release as well as completion status
  • I love the Fedora logo
  • Although development is not complete, FirewallD looks like a great idea, and is already available in Fedora 17 to some extent

The Bad

  • Hardware support out of the box is not as good as Ubuntu, mostly because of Fedora’s continued adherence to FOSS ideals. Drivers for important devices, such as wireless, require third-party repositories.
  • Moving from “desktop” to “server” in Fedora has trade offs. Either upgrade at least every year (and get the huge repository of applications) or move to RHEL/CentOS (and sacrifice in respect to the smaller repository of applications plus older software).
  • One year support, although good to stay on the cutting-edge, makes it hard to upgrade that soon. Might not be an issue with me but I can’t really recommend it to my family and friends.
  • If you want to do a fresh install three months after last GA release you have to decide if the last GA is a better bet (end of support in about 10 months, forcing a re-install) or the latest alpha or beta release (end of support in about 16 months but software stability unknown). Compare this with Ubuntu where a fresh install three months after latest final release still gives you 15 months of support and you don’t have to sacrifice stability for support.
  • It has some weird package name choices. For example, Django is called Django.noarch and other Django-related packages are called something like python-django-…noarch or similar.
  • It doesn’t have Unity desktop environment, which I think is the best for my use case
  • Multimedia support is dependent on third-party repositories
  • Some cheaper VPS providers have older versions available and it’s difficult to get a Fedora server, especially with restrictive Anaconda requirements (although they were removed before release of Fedora 17)
  • I really want to learn and like SELinux but it’s too complicated for a beginner. That’s why I have included it in this list.
  • It doesn’t have a functionality like zypper ps by default. One has to install it su -c 'yum install yum-plugin-ps'. Thanks to Equivalent of openSuse “zypper ps” on other distros? for this tip.
  • Any community documentation (blogs, wiki, etc.) can quickly get outdated between releases and it’s a mighty effort for the community to keep its documentation updated.

The Ugly

  • Haven’t seen anything ugly in Fedora

Hostname in Fedora 17

How can you change the hostname of your server running Fedora 17? The answer may not be as easy as it initially seems.

The two places where you need to have your hostname present are /etc/hosts and /etc/sysconfig/network files.

In /etc/hosts you need to have a line with the following format:

1.2.3.4 shorthostname.myexampledomain.com shorthostname

In /etc/sysconfig/network you need to have a line with the following format:

HOSTNAME=shorthostname.myexampledomain.com

Here you need to provide the FQDN, not just a short hostname, according to the Fedora 17 documentation.

After making the change in /etc/sysconfig/network run the following command and then log out and log back in to see the change.

su -c 'systemctl restart NetworkManager.service'

The Question

After going through this process you need to make sure your hostname is now correct. So you run hostname command. But wait! Instead of showing you shorthostname it shows shorthostname.mydomainexample.com. And you get the same output if you run hostname --fqdn. Why is that? Does Fedora treat an FQDN as hostname now? Is there no difference anymore?

The mystery is solved by looking at the manpage for hostname. If you use hostname --short it’ll give you shorthostname and hostname --domain will give you mydomainexample.com. In this situation if hostname gives the FQDN by default then that should be just fine, as long as us users understand the difference.

Wait and watch on systemd

I have been pondering the systemd situation for a while. My biggest concern has been that Debian and Ubuntu have not made decisions to adopt it as default, especially when Fedora, OpenSUSE, Mageia, and others have. Maybe Red Hat Enterprise Linux (RHEL) 7 will include it as well. So it seems like on the init system level, two fragmented groups are emerging: those who use systemd and those who don’t. My second concern is the ability for a casual/intermediate user to transition from a systemd-using system to one that doesn’t use it.

I have finally decided, after a long period of thinking, forecasting, etc., that I will use Ubuntu for the foreseeable future. This means that whether other distributions adopt systemd or reject it does not have much of an impact on me. If Ubuntu decides to adopt it then I’ll simply start using it. But I won’t worry about the fragmentation because it should not and does not matter to me. And it also shouldn’t matter to you either. Here’s why.

Ubuntu has been making big strides recently in adoption and popularity. More often than not you’ll find Ubuntu being deployed wholesale by organizations all over the world for desktop use. Google also uses a customized version within its own organization. Granted, Ubuntu is not as well adopted as RHEL on servers but it’s adoption is increasing at a rapid pace nonetheless. All this makes Ubuntu a viable alternative in the present and future.

Canonical, and by extension Ubuntu, sometimes does really annoying things. They have made me question my loyalty to the distribution many times. Not adopting systemd for 12.04 was one thing but to reject it outright, as Mark Shuttleworth did, did cause a bit of panic. But I overcame the systemd decision like I did other decisions because I support the diversity in the level of influence a distribution has over the future of Linux. RHEL has a big say in how organizations use Linux all over the world. Fedora, by extension, has the same influence because it prepares the technology of tomorrow. There’s a need for an equally influential player, Ubuntu in this case, to counter that excessive influence, not because RHEL is “evil” but because healthy competition is good.

Given the future viability of Ubuntu and the need to have another influential player, the fragmentation does not matter for those using Ubuntu exclusively. As long as you and I and millions more are using Ubuntu, any technology it uses to build itself is a viable and successful technology. So what if Ubuntu uses AppArmor instead of SELinux and Upstart instead of systemd? Both AppArmor and Upstart do their job and work on millions of installations.

The day when Ubuntu adopts systemd or SELinux I will happily use them. It’s not because Ubuntu can do no wrong but because I trust Ubuntu to make a better decision for millions of users than I can.

P.S. Ubuntu is not just a product. It’s a collection of people who care about FLOSS, Linux, and users. They are led, capably in my opinion, by Shuttleworth. And by joining the Ubuntu bandwagon I ensure that the product and project succeeds resulting in the success of many others tied to it.