Advertising

To offset the costs of keeping my domain running, and to help towards the new server, I’ve placed up some ads on my site. I hope that they aren’t too obtrusive, but if you think they are, feel free to let me know. Also, if you see any problem ads, please give me a heads up!

Life with Arch – Part 2: First Boot

Welcome back, and now on with part two of my Arch blog! It occurs to me that I should probably include some links at some point, but I’ll go back through later and add those in, so no worries. In this part, I’m going to go over getting essential systems up and running! So let’s get down to it.

Configuring the Network

Well, I’m not going to go into detail of every network configuration possible. I’m just going to go over dhcp. Why? Because it’s easy, and that’s what 90% of you all will be doing. I will do a static IP one, but that comes later. First things first — A lot of you older Linux users are probably familiar with ifconfig and it’s related tools. Forget about it, that’s all outdated IPv6 stuff. Yeah, sure, it’s been modified to handle IPv6, but we don’t care. We’re using IP Routes, which has been designed with IPv6 in mind. I’m not saying that necessarily makes it better, but it just is. It’s also installed by default, whereas the older linux ifconfig based utils are not. That said, ifconfig and it’s relatives are highly deprecated, so you really shouldn’t be using them anymore anyway.

This of course means that a few things have changed. Not just the commands, but the devices have changed as well. No more eth0, or wlan3, etc. Loopback is still lo, but yeah, that’s for legacy reasons. The first thing you’re going to need to do is figure out what device your network card is under. You can easily determine that by running the following command:

 

Command

ip addr

You should end up with output that will look similar to this:

Output

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp0s7: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether f8:0f:41:31:e9:a0 brd ff:ff:ff:ff:ff:ff

See that ‘2: enp0s7’? That’s the important bit right there. Well, 2 isn’t that’s just the interface marker, enp0s7 is the interface itself. It has been different on every computer I’ve ever set this up on, so keep that in mind. The parts are simple, en is for ethernet, wl is for wireless, ww is for wwlan. The rest of is a static identifier that is automatically generated for the card. That’s the part that can change on you. You can actually go in and change the names of them if you want, but that’s beyond the scope of this document, and isn’t really necessary anyway. Now, we want to enable the network so that it comes one whenever we reboot. I’m only covering ethernet connections here, but not to worry, I’m getting a new laptop, and I will go over wireless networks at a later date. To enable this network everytime we boot up, we need to use systemctl to tell systemd that we want to start this every time we run. We might want to tell systemd to start the network now as well, since that will be really useful for installing packages and talking to your lady friends on AIM ( lol ).

Commands

systemctl enable dhcpcd@enp0s7
systemctl start dhcpcd@enp0s7

There we go, network configured for DHCP and turned on! For most desktop environments, this is the most network configuration that you will need to do. I’ll get into firewalls and stuff later, for now, we just need to be connected.

Leaving Root

Running as root all the time is a bad thing. You just shouldn’t do it. Root should only be used for system administrative tasks, and for installing new packages. Right now, root is the only user on the system that can be logged into. How about we create another one. While we’re at it, let’s create a new group for the user as well. You don’t have to, but it does make for better privilege isolation (should you require it), plus it makes the user feel special.

Command

groupadd mladoux
useradd -m -g mladoux -G adm,wheel,users -s /bin/bash mladoux

Let me go over this with you for a moment. The flag ‘-m’ tells the system to create a home directory ( which you can define, but otherwise defaults to /home/$username ). The ‘-g’ indicates the users primary group, which will be the group that files save in by default when the user creates them. The ‘-G’ identifies additional groups you would like to user to belong to, I’ll go over these in a moment. The ‘-s’ is to define the shell that the user will be configured with on login, and finally the user name is the last thing on here.

About the groups, I put the user into his own group, ‘mladoux’, which carries with it no special access or privileges. I also also added him to three system groups as well. The ‘users’ group has access to standard stuff that a user might need access too, it’s limited to the most common stuff that a user “needs” to have access to, but not necessarily everything he wants to have access to. It’s quite loose for corporate environments, but if you were setting up for that, you’d probably already know a lot more about this than I’m going to discuss. The other two groups are really special, ‘wheel’ has been for as long as I can remember the default group that system admins belong too. Recently, though, that group is being replaced with adm ( short for admin, who would have guessed ). To play it safe, I put my admin users in both groups, as some legacy applications are hard coded to expect the wheel group, and some newer applications are coded in the same horrible way to expect the adm group. Most of them can be reconfigured to look at whatever group you want, but there are so many of them, who has the time. Just add admins to both groups, and no problem. This will give the user access to tools like su or sudo.

Of course, this user is still pretty useless, he has no password, he can’t login! Let’s give him one:

Command

passwd mladoux

It will prompt you for a password and to confirm the password as well. Try and make it something secure. Replace mladoux and all occurences of it in this section with your own username. Now for privilege escalation, I like to use sudo. Some people like su, hell it’s built in, but I like sudo as I can use it as a restrictive su. I can give sudo permissions to an entire group, or just one user. I can also give sudo permissions that only allow escalation when calling specific applications. Be careful about applications that provide a shell though, as they can defeat the purpose of the restriction in the first place. Also investigate any app that requires root to work very carefully, lest you give access that could potentially open your system up for harm to the wrong person. I install it as such:

Commands

pacman -Syu
pacman -S sudo

And then I add the following to /etc/sudoers so that all the members of my admin group can have access to it:

%wheel ALL=(ALL) ALL

It’s probably one of the examples in the sudoers file, so you can just uncomment it. There’s also a variation without a password, but I don’t recommend that on multi-user systems. What if an admin, because we know admins never screw up, leaves his workstation without locking it first? Well if you set it up for no password access, any person who gains physical access can just sudo anything they want. This way, it will prevent people who didn’t manage to crack his password from accessing it. If they broke his password to get into the account, well, then your screwed anyway. If their willing to take the time to do that, they’d be willing to take the time to hack the root password, even if it was different. With sudo, the root password is whatever password is associated with the user accessing, provided that user has permission to use sudo.

Now that we got that down, you’ve done the most basic of basic steps to setting up your linux system. That’s the end of this stuff, the next article will be about setting up a window manager ( XORG FTW ), specifically openbox. I’ll aslo go over nvidia drivers, since that’s what I installed on this system, and the modelines for the P125H, since that’s my monitor. Most people won’t need to mess with the modelines, and not everyone will need to worry about nVidia drivers either. When I have a computer with a different graphics card, I’ll go over the configuration for that particular card. Anyway, good night, that’s all for today. I’m going to prepare for the next entry now.

Life with Arch – Part 1: Installation

I downloaded the archlinux ISO today, and prepared a 4GB USB thumbdrive to act as an install medium. I am installing this on an eMachines EL1358G-51W that I got for around $300 USD at Wal-Mart a few years back, I’ve since upgraded my internal hard disk with a 2 TB drive from Seagate. Not sure what model, and I’m too lazy to open it up to double check. Other than that, the system is stock. The computer has 4GB’s of RAM, nVidia 6150m graphics, and an AMD Athlon 64 X2 dual core processor clocking in at 2.8 GHz each core. For a monitor, I’m using an Acer P125H, 21.5″ widescreen monitor, at 1920×1080 resolution. The monitor was a bit tricky since the computer only has VGA out, and getting it’s native resolution was a pain, seeing as it doesn’t use standard timings. I’ll make sure to share those with you. I’ll continue on from this point documenting the base installation procedure for my system.

Installing Base System

Partition Scheme

I booted into the live usb environment and used cfdisk to partition my hard disk as follows ( mine was /dev/sda ):

Partition	Filesystem	Size (MB)	Mount Point
sda1	ext2	1003.49	/boot
sda2	swap	8003.2	none
sda3	ext4	100002.96	/
sda4	ext4	1891389.3	/home

Format and Mount Partitions

Next, I formatted and mounted all the partitions under /mnt preserving the mount structure for Arch’s installation tools with the following commands

mkfs.ext2 /dev/sda1
mkswap /dev/sda2
mkfs.ext4 /dev/sda3
mkfs.ext4 /dev/sda4
mount /dev/sda3 /mnt
mkdir /mnt/boot
mkdir /mnt/home
mount /dev/sda1 /mnt/boot
mount /dev/sd4 /mnt/home
swapon /dev/sda2

Now that I had my drives all mounted up, it was time to install the base system:

pacstrap /mnt base

Once it finished installing the base packages under the /mnt directory ( where I mounted all my stuff previously ) I needed to prepare for the chroot environment. Here is everything and it’s outputs:

Create fstab

Command

genfstab > /mnt/etc/fstab

output file

# UUID=082f0129-c927-4049-b7c5-5ba3b9b81112
/dev/sda3           	/         	ext4      	rw,relatime,data=ordered	0 1

# UUID=96006174-9f9c-4306-b212-c68c249c1624
/dev/sda1           	/boot     	ext2      	rw,relatime	0 2

# UUID=a4323d9b-d7be-4e0a-8493-cdf98fcaa999
/dev/sda4           	/home     	ext4      	rw,relatime,data=ordered	0 2

# UUID=8612a863-1ed3-4e85-9b98-38830ac3c99b
/dev/sda2           	none      	swap      	defaults  	0 0

Populate locale.conf

Command

locale > /mnt/etc/locale.conf

Output File

LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

The extra LC_ALL= needes to be removed. I used nano, moved my cursor to the bottom line, and hit ctrl+k to remove the entire line. It now looks like so:

LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"

With that done, all the rest of the hardwork actually get’s taken care of by the arch-chroot script, so I ran it and entered the chroot environment

arch-chroot /mnt

See, that was easy! The system is now technically installed, but we need to do so that when we reboot that the system will be useable.

Preparing for Reboot

This next part will involve changing the contents of files that are already existing. Although the system will work with the defaults, it’s not recommended, and it may cause problems when you try to do certain things later ( especially if you run ruby or python scripts, which is just about everyone even if they don’t realize it ) so we need to get this done before rebooting.

Prepare Your Locale

Edit your locale-gen file first, I generally just move the file and start with an empty one, but the original has all the supported locale charsets defined, albeit commented out, in it. You’ll probably want to save it for later.
Commands

mv /etc/locale.gen /etc/locale.gen.orig
nano /etc/locale.gen

File

en_US ISO-8859-1
en_US.UTF-8 UTF-8

This will set up your locale for United States English. If you use a different English, please peruse the original file for your charsets. Of course, we need to actually generate the character sets at this time. The locale.gen file only configures the generation script, so let’s do that now

Command

locale-gen

Prepare Initcpio

This will make sure that all of your hardware and module dependencies are built. Make sure you do this.

Command

mkinitcpio -p linux

Set Timezone

Don’t forget to set your timezone, unless you like your computer to report your clock in UTC ( actually, set it even then ).

Command

ln -s /usr/share/zoneinfo/America/Chicago /etc/localtime

Obviously, that’s my timezone info, you’ll need to replace it with yours.

Set root Password

An operating system is especially nice when you’re able to, I don’t know, login.

Command

passwd

Just follow the on-screen instructions. It will prompt you for your password, and then to confirm it to make sure you typed it right. You didn’t think I’d tell you mine, did you?

Install GRUB

This is probably the most crucial part of this entire procedure. If you don’t install bootloader, your system does not boot… Yeah, that couldn’t possibly be bad. Anyway, let’s do this –

pacman -S grub
grub-mkconfig -o /boot/grub/grub.cfg
grub-install /dev/sda

Okay, you have officially completed the installation process, exit the chroot, and reboot the computer!

exit
reboot

First Run: Post Install

I got hungry at this point. I’ll post up the post install in the next blog post ( probably sometime later tonight or tomorrow ). In that post, I’ll go over configuring the network. The settings and what not are for my system, your system will probably require some things to be different. Hope you enjoyed this so far, and see you next time!

Fixing screen Resolution for Gnome and GDM on FC19

Have yourself a case of GDM displays in a lower resolution than you would like? Well, I have a very simple fix. First, you’ll login as your regular user and configure your resolution to be whatever you would like. I’m assuming that you’ve already gone through the pain of making it so that you don’t have to use xrandr to get those resolutions, as that is a bit beyond the scope of this document. I’m more than willing to help you out with those issues if you haven’t gotten that far.

Anyway, now you have your resolution set to whatever you need it to be. You’ll need to copy the settings file, which is located at

~/.config/monitors.xml

That file contains your display settings. In order to proceed further, you’re going to need access to root. I’m going to assume that you’ll achieve this access with sudo. Open up a new terminal and enter the following:

sudo cp .config/monitors.xml /var/lib/gdm/.config/
sudo mkdir /etc/skel/.config
sudo cp .config/monitors.xml /etc/skel/.config/

The first line copies it over to GDM’s configuration so that GDM will display at the correct resolution. The second line creates a .config directory in your /etc/skel, and then on the third line we make another copy of your monitors.xml file into the /etc/skel/.config so that when you create new accounts, they will automatically be set up with the monitors config, thus making a seamless transition for everyone. You should also copy that file into any existing users if they aren’t properly configured already.  Never again will you have to worry about a low resolution on your high resolution display.

Switching back to Fedora

I’m installing Fedora 19 now. I was on Arch for near 10 months, before that, I did a short little stint with Ubuntu. I tried openSuSE out for a bit, but ran into some into some issues that made me quickly change my mind. Currently, I’m in the process of getting my drivers and customizations up to snuff. I didn’t want to take the time to set up X11 from base again, so I elected to go straight with the defaults of Gnome 3. I’m not a fan of Gnome 3, but with enough hacking, I can make it at least bearable.

I did give KDE a spin for a bit, and it is fast, but it just has a few things about it that I just can’t quite get past. I don’t like how if my mouse gets in the upper corner, I get a display of all my windows. I don’t even have to click for this to happen, it just has to hover there for a bit. I couldn’t figure out how to disable that, and it was driving me mad. Eventually I just decided to up and switch to Gnome. I could have gone with something like Openbox, or LXDE, but I decided against it this time. They haven’t kept up with the .desktop files, so I end up having to go back through and forcing them to use the right definitions in them for menu displays. That’s just annoying as hell. If you have en_US defined as your environment variable, it better have an en_US otherwise it loads the next language ( in alphabetical order ) available. Doesn’t matter if there is en_GB, or en_AU, or even just en defined in the .desktop file, you’re getting your stuff in Armenian! I’m sure there is a way to set up a menu script that recognizes language relatives, and load definitions based on their relation to your preferred. There’s probably even a way to define more than one acceptable language. I figure that it should go to the default ( no language defined ) if your language isn’t defined, and there are no relations. Whatever, I’ve moved on.

Anyway, now I’m on Fedora 19, using Gnome 3. I couldn’t get past some of the dependency issues openSuSE was running into ( even before adding third party repos ) that really should not be issues at all. There were a few other quirks, but that was the really big one. I like Fedora, I’d prefer it wasn’t so bloated, but it’s not a bad system to be using. At least with Fedora, everything works. Well, everything that’s supposed to. You may have to hack it for edge cases, like Amazon Video, or Netflix. But you pretty much have to do that no matter which distribution you end up running. That’s what happens when companies try to keep Linux users from utilizing their services, we find a way.

Well, this post has gotten to be a bit of a rant, so I think I’ll end it here.