The Root User https://therootuser.com Ivan Windon - RHCSA Thu, 31 Jan 2019 00:09:53 +0000 en-US hourly 1 https://wordpress.org/?v=5.0.3 138440558 RHCA Journey | Lab and RHCE Objective Status https://therootuser.com/2019/01/14/rhca-journey-lab-and-rhce-objective-status/ https://therootuser.com/2019/01/14/rhca-journey-lab-and-rhce-objective-status/#respond Mon, 14 Jan 2019 18:12:33 +0000 http://therootuser.com/?p=1145 Below is a listing of the RHCE Objectives as of January 2019 on Red Hat’s website for the EX300 exam. As this week is lab practice week for me I am starting all of them off as red. This means I’ve not signed off on that objective yet as knowing it forward and backward. Many […]

The post RHCA Journey | Lab and RHCE Objective Status appeared first on The Root User.

]]>
Below is a listing of the RHCE Objectives as of January 2019 on Red Hat’s website for the EX300 exam. As this week is lab practice week for me I am starting all of them off as red. This means I’ve not signed off on that objective yet as knowing it forward and backward. Many of them will go quickly over the week as I know them fairly well already, and a few will just need a few hours of practice to ensure I do know them. So this page will be edited throughout this week as I progress. If you are interested in the progress, feel free to check back daily to see how I am doing. I will post a separate article on any challenges I faced during the labs and what I learned from the entire process.

System configuration and management

  • Use network teaming or bonding to configure aggregated network links between two Red Hat Enterprise Linux systems
  • Configure IPv6 addresses and perform basic IPv6 troubleshooting
  • Route IP traffic and create static routes
  • Use firewalld and associated mechanisms such as rich rules, zones and custom rules, to implement packet filtering and configure network address translation (NAT)
  • Configure a system to authenticate using Kerberos
  • Configure a system as either an iSCSI target or initiator that persistently mounts an iSCSI target
  • Produce and deliver reports on system utilization (processor, memory, disk, and network)
  • Use shell scripting to automate system maintenance tasks

Network services

  • Install the packages needed to provide the service
  • Configure SELinux to support the service
  • Use SELinux port labeling to allow services to use non-standard ports
  • Configure the service to start when the system is booted
  • Configure the service for basic operation
  • Configure host-based and user-based security for the service

HTTP/HTTPS

  • Configure a virtual host
  • Configure access restrictions on directories
  • Deploy a basic CGI application
  • Configure group-managed content
  • Configure TLS security

DNS

  • Configure a caching-only name server
  • Troubleshoot DNS client issues

NFS

  • Provide network shares to specific clients
  • Provide network shares suitable for group collaboration
  • Use Kerberos to control access to NFS network shares

SMB

  • Provide network shares to specific clients
  • Provide network shares suitable for group collaboration

SMTP

  • Configure a system to forward all email to a central mail server

SSH

  • Configure key-based authentication
  • Configure additional options described in documentation

NTP

  • Synchronize time using other NTP peers

Database services

  • Install and configure MariaDB
  • Backup and restore a database
  • Create a simple database schema
  • Perform simple SQL queries against a database

Red Hat Training Labs

  • Lab: Controlling Services and Daemons
  • Lab: Managing IPv6 Networking
  • Lab: Configuring Link Aggregation and Bridging
  • Lab: Network Port Security
  • Lab: Managing DNS for Servers
  • Lab: Configuring Email Transmission
  • Lab: Providing Block-based Storage
  • Lab: Providing File-based Storage
  • Lab: Configuring MariaDB Databases
  • Lab: Providing Apache HTTPD Web Service
  • Lab: Writing Bash Scripts
  • Lab: Bash Conditionals and Control Structures
  • Lab: Configuring the Shell Environment
  • Lab: Comprehensive Review of System Administration III

Notes

The first 5 labs have gone very well, as I am able to do them without looking at the answers. While I may not recall all the full commands on some of them, it is easy enough to locate the correct syntax using man pages and using semanage or error logs to resolve the issues. The same methods I will have at my disposal during the EX300 exam.

The SMTP mail relay section seems to be giving me issues. The labs have you just issuing out long postconf -e commands to insert or change the /etc/postfix/main.cf file. I haven’t found a way to recall all these commands by memory just yet, other than just drilling it over and over until I have them memorized. I’m more going on the line of thinking of instead of using postconf -e I will just edit the main.cf file directly and recall each area to locate in the file to accomplish what I’m needing to do. I will need to review this lab a few more times before I feel I am ready, therefore I marked it as orange.

The iscsi configuration took me a little longer than the others as there are a number of steps involved in setting it up on the server, and then connecting on the client. However after going over the labs a number of times I understand the syntax of each of the commands for discovering, logging in, logging out, and even deleting. I also understand the process of setting up the server side with targetcli. If I draw a blank I can use man iscsiadm to see the required examples needed for the syntax I’ll need to connect the client to the server target.

It took a while for me to get all the NFS and SMB objectives down in the labs. I am not sure what I’ll be asked to do in the exam, however at this point I have it down well enough that I feel comfortable moving forward. The next day or two I will be working on MariaDB and Apache in the labs. I took some time off (as I was on vacation after all, and I got sick at the end of the week). I hope to be at the point at the end of this week I’ll feel comfortable scheduling the exam and giving it a go.

I’ve done most of the labs at this point, and some of them I can redo without issue. I’m placing a check next to all that I’ve gone over a second time, and that are firmly in my memory. I will be scheduling my EX300 exam in the next few days, more than likely for some time near the end of February. I just need the extra time to go over the labs until I am comfortable with them.

Last updated: January 30, 2019 at 5:11 PM MST.

The post RHCA Journey | Lab and RHCE Objective Status appeared first on The Root User.

]]>
https://therootuser.com/2019/01/14/rhca-journey-lab-and-rhce-objective-status/feed/ 0 1145
RHCA Journey – Week 3 | Bash Scripting https://therootuser.com/2019/01/11/rhca-journey-week-3-bash-scripting/ https://therootuser.com/2019/01/11/rhca-journey-week-3-bash-scripting/#respond Sat, 12 Jan 2019 06:17:06 +0000 http://therootuser.com/?p=1139 It’s been about a week since my last post. I was able to finish up the first review of the RHCE material with Red Hat’s training material. I was slowed down however due to taking care of things at home, plus just extra busy days at work. The good news is, I had some extra […]

The post RHCA Journey – Week 3 | Bash Scripting appeared first on The Root User.

]]>
It’s been about a week since my last post. I was able to finish up the first review of the RHCE material with Red Hat’s training material. I was slowed down however due to taking care of things at home, plus just extra busy days at work. The good news is, I had some extra time I needed to take before my PTO expired so I am taking it now. I’ll have all next week to do some resting, as well as finish my studies for my RHCE. At the end of next week, I will be scheduling my exam.

The last bit of information in the training was on Bash shell scripting and shell variables. Nothing too difficult, just things that require use and practice and you will have no problems with it. Bash scripting is obviously good for automating various system administrative tasks, so it’s good to know this.

This is just a short update though, and not really going over too much detail over the last bit of information covered at this time. That will be saved in my second pass where I focus more on lab examples and reviewing the material and objectives over the next week.

My plan for next week is to do two posts, one mid-week, the second at the end of my training for the RHCE. The exam will be scheduled for sometime that following week, or as soon as a spot is open for a Kiosk type exam.

So the next update should be posted on Wednesday to update on my final study week. Most of it will just be practicing doing the various objectives for the RHCE and making sure I can either recall how to do it all from memory or know where I can find examples of the commands in man pages so I can accomplish the tasks quickly.

Cheers,

Ivan Windon – RHCSA

The post RHCA Journey – Week 3 | Bash Scripting appeared first on The Root User.

]]>
https://therootuser.com/2019/01/11/rhca-journey-week-3-bash-scripting/feed/ 0 1139
RHCA Journey Day 8 – MariaDB | Apache and TLS https://therootuser.com/2019/01/02/rhca-journey-day-8-mariadb-apache-and-tls/ https://therootuser.com/2019/01/02/rhca-journey-day-8-mariadb-apache-and-tls/#respond Thu, 03 Jan 2019 00:43:26 +0000 http://therootuser.com/?p=1131 It has been a few days since my last post, however, the studying continued on each day. I covered MariaDB, Apache, and TLS just recently. I really enjoyed the topics that I covered over the past few days as I was able to directly apply them to real-world situations with this website. What made this […]

The post RHCA Journey Day 8 – MariaDB | Apache and TLS appeared first on The Root User.

]]>
It has been a few days since my last post, however, the studying continued on each day. I covered MariaDB, Apache, and TLS just recently. I really enjoyed the topics that I covered over the past few days as I was able to directly apply them to real-world situations with this website.

What made this especially fun was that my website is run off all of these. Until today though the site was just run over HTTP, after reading up on getting TLS working on Apache I figured, why not just put into practice what I learned by adding TLS support to this site. You may notice that now the site is fully https, and it redirects you to https automatically now. I did not go for the expensive ones, as I don’t sell anything on this site, so there was no need. So I just went for the DV (domain verification) certificate from Comodo.

I just needed to install two packages to get things going:

# yum install mod_ssl crypto-utils

From there I ran genkey to get my csr.

# genkey www.therootuser.com

Just follow the on screen prompts, and it dumps the file out at /etc/pki/tls/certs/www.therootuser.com.0.csr, which you then send to the CA to get signed (along with some money).

Then I just edited the file /etc/httpd/conf.d/therootuser.conf

SSLEngine on
SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite HIGH:3DES:!aNULL:!MD5:!SEED:!IDEA
SSLCertificateFile /etc/pki/tls/certs/www_therootuser_com.crt
SSLCertificateKeyFile /etc/pki/tls/private/www.therootuser.com.key
SSLCACertificateFile /etc/pki/tls/certs/www_therootuser_com.ca-bundle

These were all added to the <VirtualHost *:443> section of the conf file

As this process took me time to figure out and get working properly it, of course, slowed me down on the Apache section, so I’m still finishing that chapter up and will take what I learn from there and apply it to make my site better.

With MariaDB, most of that was just review material, and the only syntax I think I’ll need to work on to get down correctly is creating users, and granting rights to them. For my purposes, it’s not something I really have to deal with, but it will still be useful to know.

For now, I will continue on with the Apache chapter, and try and apply things to my site, as well as in lab situations. At least I’m sure on this topic I will do well on the exam. Which knowing my luck, they won’t ask anything about. Usually how it goes. Check back tomorrow for more on Apache, and my next topics on the RHCE.

Cheers,

Ivan Windon – RHCSA

The post RHCA Journey Day 8 – MariaDB | Apache and TLS appeared first on The Root User.

]]>
https://therootuser.com/2019/01/02/rhca-journey-day-8-mariadb-apache-and-tls/feed/ 0 1131
RHCA Journey – Day 5 – 6 – Email and iSCSI https://therootuser.com/2018/12/30/rhca-journey-day-5-6-email-and-iscsi/ https://therootuser.com/2018/12/30/rhca-journey-day-5-6-email-and-iscsi/#respond Mon, 31 Dec 2018 02:56:43 +0000 http://therootuser.com/?p=1127 The weekend I continued on my RHCA Journey with my RHCE studies by covering chapters on configuring email transmission with RHEL. The bigger chapter went over providing remote block storage with iSCSI. Both topics are fairly new to me as it is not something I’ve had to deal with much in the past. Both are […]

The post RHCA Journey – Day 5 – 6 – Email and iSCSI appeared first on The Root User.

]]>
The weekend I continued on my RHCA Journey with my RHCE studies by covering chapters on configuring email transmission with RHEL. The bigger chapter went over providing remote block storage with iSCSI. Both topics are fairly new to me as it is not something I’ve had to deal with much in the past. Both are topics though that interest me and I want to know more about.

The email chapter was fairly basic, just covering relaying local messages from the system to a mail system, nothing like setting up a full-blown mail server. The full mail server is something I have wanted to do for a while, just to see how it all works. I have done so with an Exchange server in the past, however, my email server is now hosted by Rackspace. I would love to set up my own mail server and host my own email, as I do with my website. I have read that this is not a recommended thing to do, for security issues and such. I think I’ll still try it one day, as the process sounds challenging and fun.

The biggest chapter which I went over today actually was on iSCSI. I’ve done it myself a few times in the past, but I still haven’t wrapped my head around it all just yet. I feel I need to read over this chapter a few more times and use my other sources as well to see how they explain it. A while back I set up an iSCSI target on a Synology NAS, so it was interesting to see it in a non-lab type setup. I think that helped me understand it a bit better. What I just need to do is read over the material a few more times to understand why I’m doing what I am doing, and then just practice setting it up a few times until I get it into my memory better.

At this point, I have gone through half of the training material for the RHCE. I should be able to finish in the next week and then start reviewing the areas I’ve determined to be weak points for me and going over the labs a number of times. I will then have a better idea on when I’ll schedule the RHCE exam.

Tomorrow I will begin a chapter on File-based storage with NFS and SMB, so that should be exciting and a good review. Be sure to check back again tomorrow for more information on how that goes.

Cheers,

Ivan Windon – RHCSA

The post RHCA Journey – Day 5 – 6 – Email and iSCSI appeared first on The Root User.

]]>
https://therootuser.com/2018/12/30/rhca-journey-day-5-6-email-and-iscsi/feed/ 0 1127
RHCA Journey – Day 4 – DNS and unbound https://therootuser.com/2018/12/29/rhca-journey-day-4-dns-and-unbound/ https://therootuser.com/2018/12/29/rhca-journey-day-4-dns-and-unbound/#respond Sat, 29 Dec 2018 14:00:49 +0000 http://therootuser.com/?p=1073 Day 4 of the RHCA Journey, studying for the RHCE portion, was about DNS. Specifically how it works, how to diagnose DNS issues, as well as how to build an unbound DNS Cache server. One point I found worth noting, was that before blaming the issue on DNS, as we all know that if something […]

The post RHCA Journey – Day 4 – DNS and unbound appeared first on The Root User.

]]>
Day 4 of the RHCA Journey, studying for the RHCE portion, was about DNS. Specifically how it works, how to diagnose DNS issues, as well as how to build an unbound DNS Cache server.

One point I found worth noting, was that before blaming the issue on DNS, as we all know that if something is wrong, it is always a problem with DNS, is that we should look into the /etc/nsswitch.conf file and verify the order in which name resolution takes place.

# cat /etc/nsswitch.conf | grep hosts

hosts:      files dns myhostname

As you can see from the results of the above command the order is first files (such as /etc/hosts), then it goes to DNS. So the FIRST place you should look when troubleshooting is /etc/hosts and ensure the problem doesn’t lay there, then you can use tools such as DIG to investigate further.

The rest of the chapter on DNS covered how to set up and configure the unbound name server on RHEL. The process is fairly simple, and by just practicing the process a few times you’ll be able to do it in your sleep. One thing to make sure you remember, I’ve even forgotten it myself, is adding the service with firewall-cmd once you are done configuring unbound at /etc/unbound/unbound.conf. You will want to run the following commands:

# firewall-cmd –permanent –add-service dns

# firewall-cmd –reload

I have an article detailing the entire process of setting up an unbound server. The article even includes a video that you can watch. I used this process a while back when I set up my own DNS unbound server in my home network. I use it in conjunction with the DHCP server, also running on RHEL and the IDM server, which then all integrate into my Satellite server.

Tomorrow as I do not have to work, I am hoping to get a little more study time than I have been getting. I will also use it for a time to review some of my information I have learned this previous week. Out of all the ones this week so far, I’d say the one I need most work on is the adding a network team to a software bridge. So my review will focus mostly on that.

In the mean time, check back tomorrow for my next post on what I covered on Day 5.

The post RHCA Journey – Day 4 – DNS and unbound appeared first on The Root User.

]]>
https://therootuser.com/2018/12/29/rhca-journey-day-4-dns-and-unbound/feed/ 0 1073
RHCA Journey – Day 3 https://therootuser.com/2018/12/28/rhca-journey-day-3/ https://therootuser.com/2018/12/28/rhca-journey-day-3/#respond Fri, 28 Dec 2018 15:51:15 +0000 http://therootuser.com/?p=1070 On day 3 of my RHCA Journey, I went over the topics of firewalld (standard, and rich rules), masquerading, port forwarding, and SELinux. I like Linux security to begin with, so it was a fun chapter for me. As usual though I found a few areas of which I need to work upon, but nothing too […]

The post RHCA Journey – Day 3 appeared first on The Root User.

]]>
On day 3 of my RHCA Journey, I went over the topics of firewalld (standard, and rich rules), masquerading, port forwarding, and SELinux. I like Linux security to begin with, so it was a fun chapter for me. As usual though I found a few areas of which I need to work upon, but nothing too difficult, because of man pages. One key thing learn for any Red Hat exam is to understand you may not recall everything, so another good option is to learn WHERE you can find the needed information without using the Internet. This is where man pages come into play. For instnace lets say you forget the syntax of a rich rule, you can run the following command:

# man firewalld.richlanguage

Then looking toward the end in the example section you see a variety of options in which you could build your own rich rule with firewalld.

# firewall-cmd –permament –add-rich-rule ‘rule family=”ipv4″ source address=”192.168.0.0/24″ service name=”tftp” log prefix=”tftp” level=”info” limit value=”1/m” accept’

# firewall-cmd –reload

I liked the SELinux portion as well, as I am a big believer in using SELinux and always keeping it on. In this chapter, it focused on SELinux on port security. Usually, you’ll need to use SELinux to add a custom port when running applications, such as web servers, on non-standard ports. If this is the case, with SELinux running, httpd would fail to load if it is listening in on a non-standard port. The easiest way to find this information is by using the following command:

# sealert -a /var/log/audit/audit.log

For issues with being denied access based on a non-standard port, sealert will give the reason why, and provide the syntax to add it. You just need to know the SELinux port type to plug in. For http, it would be http_port_t. The command then would be to do:

# semanage -a -t http_port_t -p tcp 82

The -a is to add the new port, the -t is the type, in our case http_port_t, and the -p is the port, where you pick if it’s tcp or udp and the port number required. Of course don’t forget to add the port in the firewall as well:

# firewall-cmd –add-port 82/tcp –permanent

# firewall-cmd –reload

After which you can restart the httpd service and all will be well.

In all, it was a fun chapter to go through, and with a bit more practice I believe I’ll do well on this portion. Hopefully today I will get more time than I have the past few days. As I have only been able to hit one chapter at a time, however in some sense it was good, as I was able to spend more time on each single topic. Be sure and check back tomorrow to see the next topic that I will cover today.

Cheers,

Ivan Windon – RHCSA

The post RHCA Journey – Day 3 appeared first on The Root User.

]]>
https://therootuser.com/2018/12/28/rhca-journey-day-3/feed/ 0 1070
RHCA Journey – Day 2 https://therootuser.com/2018/12/27/rhca-journey-day-2/ https://therootuser.com/2018/12/27/rhca-journey-day-2/#respond Thu, 27 Dec 2018 14:24:17 +0000 http://therootuser.com/?p=1065 It was a busy day at work, so I was unable to spend as much time on training today, therefore only one chapter was covered.  It was a good one, and a found a weakness that I need to work on.  On day two I covered network teaming, and software bridges. Now either of those […]

The post RHCA Journey – Day 2 appeared first on The Root User.

]]>
It was a busy day at work, so I was unable to spend as much time on training today, therefore only one chapter was covered.  It was a good one, and a found a weakness that I need to work on.  On day two I covered network teaming, and software bridges.

Now either of those alone, easy.  Just use nmcli and off you go, create the team such as:

nmcli con add type team con-name team0 ifname team0 config ‘{“runner”: {“name”: “activebackup”}}’

Then add in the interfaces such as:

nmcli con add type team-slave con-name team0-port1 ifname eno1 master team0

nmcli con add type team-slave con-name team0-port2 ifname eno2 master team0

Of course, adding IP information to the team interface:

nmcli con mod team0 ipv4.addresses 192.168.0.15/24 ipv4.method manual

Then you got yourself a spiffy new team.  Bridges are fairly similar and just as easy via nmcli.  However, where it because a little more tricky is if you want to have a team be part of a bridge, as you can’t use network manager to configure it, or control it.  So you have to first disable your team with nmcli dev dis team0, then disable network manager with disable NetworkManager and stop NetworkManager, then you have to edit and create files manually within /etc/sysconfig/network-scripts/ifcfg*, editing the ifcfg-team0 file, as well as each slave interface, and then creating a new ifcfg-bridge file, and assigning it an IP address.

It’s not “difficult” per se, just have to recall what needs to be added to the file, either by memory, and locating the example information in a man page to compare it with.  As there are only a few lines, I will go with just memorizing the information.

Later on, I will create a post that covers in detail how to do network teaming and software bridges with examples on each.  I’ll be reviewing this information further as well until I have it down, just in case on the exam they want me to do both.

Today, the next chapter goes over firewalld and port security.  So that should be fun.  As for my daily posts, I shifted them to be in the mornings each day, instead of at the end of the day.  I ran out of time yesterday, and this will just work better I think.  So tune in tomorrow morning again for Day 3.

Cheers,

Ivan Windon – RHCSA

The post RHCA Journey – Day 2 appeared first on The Root User.

]]>
https://therootuser.com/2018/12/27/rhca-journey-day-2/feed/ 0 1065
RHCA Journey – Day 1 https://therootuser.com/2018/12/25/rhca-journey-day-1/ https://therootuser.com/2018/12/25/rhca-journey-day-1/#respond Wed, 26 Dec 2018 06:31:09 +0000 http://therootuser.com/?p=1063 Today was the first day of my RHCA goal.  I have three different training options.  I like having more than one, just to help round things off.  Sometimes I end up getting a better sense of something from another source, so having a few options just allows me to learn the material better.  However it’s […]

The post RHCA Journey – Day 1 appeared first on The Root User.

]]>
Today was the first day of my RHCA goal.  I have three different training options.  I like having more than one, just to help round things off.  Sometimes I end up getting a better sense of something from another source, so having a few options just allows me to learn the material better.  However it’s less of an issue with Red Hat exams as the end result on the exams is what counts, how you get there is up to you.

To study I’m using the following:

Today was fairly light though, and I just used the Red Hat Learning Subscription and went through the first two chapters.  Which focused on Systemctl, the boot process, resetting the root password.  The second chapter went into network manager, and creating connections and assigning ipv4 and ipv6 address information.

In all, it was fairly basic material that I’ve dealt with before.  The good news was I recalled all the nmcli commands from memory, even though many times I tend to use nmtui when configuring interfaces (not sure why, as it’s just as easy with nmcli).

The labs went well too, and I was able to pass them all on the first round and didn’t require looking anything up.

Tomorrow will be more training, need to do at least 2 to 3 chapters a day to stay on track.  Be sure to come back tomorrow to see more progress.

Cheers,

Ivan Windon – RHCSA

The post RHCA Journey – Day 1 appeared first on The Root User.

]]>
https://therootuser.com/2018/12/25/rhca-journey-day-1/feed/ 0 1063
RHCA Journey https://therootuser.com/2018/12/24/rhca-journey/ https://therootuser.com/2018/12/24/rhca-journey/#respond Tue, 25 Dec 2018 01:03:17 +0000 http://therootuser.com/?p=1060 I have decided to make obtaining my RHCA (Red Hat Certified Architect), my primary goal for the year 2019.  I have the RHCSA (Red Hat Certified Systems Administrator) certificate already, so my next step is to step up to the RHCE (Red Hat Certified Engineer).  My goal is to study for and pass the RHCE […]

The post RHCA Journey appeared first on The Root User.

]]>
I have decided to make obtaining my RHCA (Red Hat Certified Architect), my primary goal for the year 2019.  I have the RHCSA (Red Hat Certified Systems Administrator) certificate already, so my next step is to step up to the RHCE (Red Hat Certified Engineer).  My goal is to study for and pass the RHCE in the month of January.  After which I will need to pick an additional 5 exams, which I will attempt every two months.  If all goes well, and I’m able to stick with this plan I will finish in November of 2019.

At the “moment” I am considering the following as my additional five.

It should be an interesting and very busy year, to say the least.  I look forward to the challenges, and growth this journey will give me.  My plan is to update this blog on my progress as I go along, and include what I find interesting in my studies, as well as what I find challenging as I study the material further.  I will also comment on how I did on the exams, however, as you know I will not be able to discuss what was actually on the exam.  I am sure though I can state if I felt the study material I used prepared me adequately for the exam or not.  The good things about Red Hat exams are that they are all practical hands-on exams.  So as long as you can perform the tasks in the objectives for each exam you are taking, and do it fairly quickly, then passing each exam should not be an issue.

In the meantime, look for the next upcoming post on my study efforts with the RHCE.  This one should go quicker than maybe the others as I’ve been using RHEL for some time, so I just need to practice some labs and make sure I can perform all the objectives without issue before I schedule my next exam in January.

As for when I will start my RHCE studies, that will begin tomorrow, December 25th.

Cheers,

Ivan Windon – RHCSA

The post RHCA Journey appeared first on The Root User.

]]>
https://therootuser.com/2018/12/24/rhca-journey/feed/ 0 1060
Mounting Linux volumes with systemd vs fstab https://therootuser.com/2018/05/02/mounting_linux_volumes_with_systemd_vs_fstab/ https://therootuser.com/2018/05/02/mounting_linux_volumes_with_systemd_vs_fstab/#respond Wed, 02 May 2018 23:21:09 +0000 http://67.40.147.70/?p=264 Mounting Linux volumes with systemd vs fstab If you have ever done anything more than just an out of the box linux installation you have more than likely worked with fstab to get your volumes to mount. The screenshot to the left shows and example of an fstab file. In this example we are going […]

The post Mounting Linux volumes with systemd vs fstab appeared first on The Root User.

]]>
Mounting Linux volumes with systemd vs fstab

fstab file viewed in VIMIf you have ever done anything more than just an out of the box linux installation you have more than likely worked with fstab to get your volumes to mount. The screenshot to the left shows and example of an fstab file. In this example we are going to look at /dev/sda6 which is mounted to /apps using the XFS file partition and using the defaults. In the sample fstab file you will also notice other volumes mounted using UUID and also the volume label. The UUID you can get by running blkid at the command prompt. Both the UUID and label methods are best as things can change in the system that would change the /dev/sda6 name at which point you’ll have issues with your mounts.

I know that Red Hat is going to be using the systemd method of mounting in future versions of Red Hat, so it would be good to understand this way of doing it. In all it is not that much more difficult to setup as before, however the mounts will all be controlled via the systemd process and you can use commands such as systemctl status, start, enable, and disable on your individual mounts.

The first step is to get a sample .mount file that you can edit for your purposes. These files are located on your system at /lib/systemd/system. When you are in this path you can do a ls *mount to get a listing of all the various .mount files available. A good one to choose is the tmp.mount file. We need to copy this file to /etc/systemd/system/.

cp tmp.mount /etc/systemd/system/apps.mount

You want to pick a name that will be descriptive of what you are mounting. In this example we are mounting an apps volume, so that is why I chose the apps.mount filename.

We can then use vim to edit the file and change it to meet our requirements. We can remove any Systemd configuration fileinformation related to the tmp.mount file, and add the proper information to have our apps volume mount. In the screenshot to the right you see an example of what the file should look like. Under the [Mount] section we can enter the following:

  • what=UUID=”277927f6-a97a-4580-b409-eb9b6cb09fca”
  • where=/apps
  • type=xfs
  • options=defaults

As you can see the format is similar to what you have done in the fstab before. Once you have this done you can save your file, and then it all comes down to standard systemctl commands. Instead of all being on one line you enter them on four separate lines. Also the use of UUID=”277927f6-a97a-4580-b409-eb9b6cb09fca” instead of /dev/sda6 is preferred to prevent issues if the device names change due to a file system reconfiguration later on. Remember, you can see what the UUID of any device is by running the blkid command.

 

Systemctl daemon-reload
Systemctl start apps.mount
Systemctl status apps.mount
Systemctl enable apps.mount

Systemctl status apps.mountDon’t forget to add the .mount at the end, as if you forget systemctl will think you are talking about a service and the command will fail. Also be sure as with fstab and any other manual mounting method you have the mount point created, in our chase /apps.

At this point the volume will mount each time the system starts via systemd. You’ll be able to remove this entry from your fstab file.

I hope you found this article informative. If you have any questions, feel free to reach out to me.

Cheers,

Ivan Windon – RHCSA

The post Mounting Linux volumes with systemd vs fstab appeared first on The Root User.

]]>
https://therootuser.com/2018/05/02/mounting_linux_volumes_with_systemd_vs_fstab/feed/ 0 264