GhostBSD for home and office users

GhostBSD is a super user-friendly FREE operating system based on FreeBSD. Whilst FreeBSD is more for server and network administration side, GhostBSD is much more pretty for workstations. If you are thinking of having a much more secure desktop environment, I would surely advise GhostBSD.



bsdghost
Photo credits ghostbsd.org

GhostBSD shares many of the same features as FreeBSD, including:


  • Integrated Firewalls, Jails, Linux emulation, Network Virtualization, and bhyve.
  • KMS and new drm2 video drivers
  • The FreeBSD ports collection
  • The New Binary Packaging System pkgng

GhostBSD added a few extra features of its own, including:

  • A user-friendly installation process
  • Automatic detection of your computer’s hardware
  • Automatic configuration of your network card
  • Pre-installed desktop environments
  • Pre-installed codecs to play multimedia files

Let’s see how to install GhostBSD on a Virtual Box Virtual machine. You can also try it on a virtual machine.

1. Download the ISO at the official website.

2. Create your Virtual machine and boot your ISO. It will prompt you for Graphical Install only, Failsafe mode and ACPI off. Well, choose the Graphical Install mode.

Screenshot from 2015-11-25 18:46:40

3. After some minutes, it would log in automatically on the GUI interface. You also choose your ISO as per your best desktop environment.

Screenshot from 2015-11-25 18:49:02

4. Double click on the GhostBSD Installer icon. Then choose your language, keyboard, time zone and use the entire disk partition if you are not familiar with disk partitioning on BSD. You will need to complete some formalities about the User Setup. And GhostBSD is going to install pretty much easily.


What is most interesting is that by default on GhostBSD, you have the FISH shell. There are several features with FISH such as auto-completion and color readable commands suggesting you, for example, a directory path. This is much pretty useful for beginners using BSD to be able to cope with all the commands easily. Welcome to GhostBSD. The adventure starts now.

 More article on BSD:

Adding a new disk on FreeBSD from VirtualBox

Tips:

Sometimes, on Virtualbox, you need to remove the ISO after installation as it will prompt you to install again. I noticed that after installing GhostBSD compared to a CentOS installation which ejects the ISO automatically after installation.


Some basics of UEFI and BIOS

The BIOS (Basic Input Output Settings) and UEFI (Unified Firmware Extensible Interface) are two different types of firmware interface that enable the interaction between the mechanisms of your machine hardware and its firmware. It is a type of “program” or “firmware” that initialize the boot process through your hardware. Your machine cannot boots up without this mechanism. Let’s see the main differences between BIOS and UEFI.


Photo credits: Scott Mueller
Photo credits: Scott Mueller – From the book Upgrading and Repairing PCs

BIOS

When a machine boots up with BIOS, it reads the first boot sector in a hard disk followed by the normal boot process. One interesting thing is that BIOS basically runs a 16-bit (in real mode), 32-bit (protected mode) and 64 bit (Long mode) and during the boot up the BIOS is assigned 1MB of address space where it reads the MBR (Master Boot Record) file to understand the Machine partitions. You can activate the BIOS interface on VMware by clicking on VM -> Power -> Power on BIOS.

UEFI

So, UEFI is a sort of the next generation “firmware” replacing BIOS. It has been built with a better graphical interface since it performs in 32 bit or 64-bit mode. UEFI on the other hand when boots up uses the GPT (GUID Partition table); GUID is another abbreviation stands for Globally Unique IDs. With UEFI, you have the following advantages:

  • Managing disk of size more than 2.2 TB
  • Partition entries backup
  • Advanced network functionality
  • 64 Bit architecture support

In brief, UEFI boots up by loading several .efi files from a partition to the hard disk ESP (EFI system partition) which is a partition in itself.


Ruby on Rails deployment on Ubuntu Server

Ruby on Rails is a web application framework that enables you to develop web applications. It uses the Mobile-View-Controller (MVC) mechanism by providing default structures for the databases, web services and web pages. This article will be based on the installation and brief overview of Rails, Ruby, Ruby Version Manager (RVM) and Rubygem. I am using an Ubuntu Server 15.10 for the deployments.



Ruby_on_Rails.svg

To install Rails, you need to have Ruby which is an open source programming language. There are different ways to install Ruby. You can install it with your apt-get or yum tools which will not give you the latest version by default. You can download and compile it from source or you can also use the RVM Ruby Version Manager. The RVM permits you to switch between environments and different Ruby versions within the same machine easily. The community of Ruby developers is moving at a fast pace. It’s very difficult to manage your Ruby applications without having a proper control over the different environments especially when an application is migrated from the Dev to Prod environment. There is another tool called Rbenv which can use to switch between environments. Let’s install Ruby on Rails! 🙂

1. Basically, an apt-get install ruby will install ruby with all dependencies. However, from the Ubuntu repo, the version is 2.1 To install it with RVM, you need to install RVM itself first. I installed it using CURL


apt-get install curl

2. install mpapis public key as per official documentation.

gpg --keyserver hkp://keys.gnupg.net --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3

3. Install RVM – stable version. You would notice several dependencies being installed such as g++, gcc, make etc..

curl -sSL https://get.rvm.io | bash -s stable --ruby

4. To start using RVM, you need to run


source /usr/local/rvm/scripts/rvm

5. You can check your RVM version and update your RVM version with the commands below. More information is also available on  GitHub rvm repo

rvm -v

rvm get head

rvm reload

rvm get stable

6. You can check if all dependencies are installed with the command

rvm dependencies

7. Install Ruby with the command


rvm install ruby. 

8. To use the default version of ruby, you just need to do a

rvm use ruby --default. 

Note that when RVM is installed,  by default it installs a version of Ruby.

9. Normally, after installing RVM, RubyGems, which is a package management framework for Ruby will also be installed alongside. Verify it with the command

rvm rubygems current. 

10. However, if you need to upgrade to the latest RubyGems you need to do a

gem update --system. 

11. Rubygem itself can be updated provided you install the rubygems-update gem. Do a

gem install rubygems-update 
update_rubygems.

12. To install Rails alongside with all documentation

gem install rails

13. At this stage, we have already installed Ruby on Rails on our Ubuntu server. I will now get into some more details. Since we downloaded the default Ruby, through RVM at step 8, you would notice that you do not have the latest Ruby version! To download the latest stable release which is Ruby-2.2.3 at the time I am writing this article.

rvm install 2.2.3

14. You switch on to the new Ruby-2.2.3 with the command

rvm use ruby-2.2.3

15. Right now, I have Ruby-2.2.1 which is the default version that I have to install alongside RVM and Ruby-2.2.3 which I have manually downloaded at step 13. Supposed we have to test an application with Ruby-2.1.7, lets now download another Ruby i.e; Ruby-2.1.7

rvm install 2.1.7

16. Once the Ruby-2.1.7 is downloaded, we switch on to it (see step 14). At this stage, you would also notice that the PATH of your ENV has changed. Each time you change the Ruby version, you would notice a change in the path.

Screenshot from 2015-11-11 18:14:28

17. Assuming we no longer need this version, lets now purge and uninstall Ruby-2.1.7 After uninstalling repeat the version you want to use at step 14


rvm uninstall 2.1.7

There are other tools such as Rbenv and Chruby which you can use instead of RVM to manipulate Ruby version. There are however its pros and cons when it comes to Rbenv VS RVM.


Anatomy of a simple dig result

The ‘dig’ (Domain Information Gropper) command is one of the tools which is frequently used to troubleshoot DNS and BIND configurations. Its main purpose is to perform DNS lookups and query DNS servers. Though the subject is vast, I decided to blog some DNS stuff under the ‘Bind and DNS tools’ category which I just created. I will keep on updating this article as I keep on finding interesting dig commands.


Screenshot from 2015-11-08 15:45:52

Let’s analyze the result from a simple dig google.com. You would have a result similar to this one (In green). By default, dig perform query A record when launched without any arguments.

1. I made a dig google.com on my Linux terminal

[[email protected] ~]# dig google.com

2. The header section starts here. Several files in /etc/ld.so.* is being read and the dig command will also launch a uname with the argument sys and node. The uname is already inbuilt in the code of the dig command. It then reads the /etc/resolv.conf


; <<>> DiG 9.9.4-RedHat-9.9.4-18.el7_1.5 <<>> google.com

3. The ;; global options: +cmd is referred to the default arguments sets by dig to use only the +cmd variables.  The opcode value is always static. The status is to inform us if any error occurred during the query. Each query is also associated with an id number ( ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35133).

The flags qr (query response), rd (recursion desired) and ra (recursion available) are also information retrieved from the DNS header. As per the IETF RFC1035, when a dig with the default arguments is performed it will flag the qr, rd, ra and when the bit is 1 it’s a response and 0 for a query. Therefore ‘qr’ appears as 1

The ANSWER:2 is the numbers of answers received in the Answer section, same for QUERY, AUTHORITY and ADDITIONAL.


 ;; global options: +cmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35133
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

4. The “question section” is what you are querying for. In this case, a ‘dig’ has been done on the A record. An A record simply means Adress i.e; the address associated with the website. We have several DNS records types which I will elaborate in future articles.

;; QUESTION SECTION:
 ;google.com.            IN    A

5. The number 173 is the TTL (Time To Live), IN refers to Internet i.e the class in which it is. TTL  is a 32 bit signed integer which corresponds to the time interval a record can be cached before the information is again queried. A TTL zero is used for extremely volatile data.

To resume we read it as follows: Google.com has a 173 seconds Time To Live on the Internet with the IP Address 74.125.226.168


;; ANSWER SECTION:
 google.com.        173    IN    A    74.125.226.168
 google.com.        173    IN    A    74.125.226.162

6. This section acts like a stat section. Information is given about the time it takes to query. The server IP address i.e; 4.2.2.1 and the port number 53 which is associated with it. The date and finally the message size received is 204 bytes.

;; Query time: 22 msec
 ;; SERVER: 4.2.2.1#53(4.2.2.1)
 ;; WHEN: Sun Nov 08 01:19:23 EST 2015
 ;; MSG SIZE  rcvd: 204

More analysis can be performed by launching a strace in front of a dig command. The RFC 1035 is also of great help. You can also check out the Internet System Consortium (ISC) website for more details.

Tips:

  • dig -t MX google.com will show you in the list of MX records in the ‘Answer Section’
  • A  dig result is compose of only 5 parts i.e; Header, Question (question for the name server), Answer (resource records answering the question ), Authority (resource records pointing towards an authority) and Additional (resource records holding additional information).
  • To filter information from a default dig command you can use dig google.com +nocomments +noauthority +noadditional +nostats which will give you only the answer. With an additional +noanswer wont give you anything.
  • However, the reverse way to filter dig results with a specific answer can be dig google.com +noall +answer will give you only the answer section.



Simple Master-Master replication on MariaDB

Lets set up a simple Master-Master database replication on MariaDB. I have already posted an article on the setting up of a Master-Slave database replication. You can test it on Virtual Box or Vmware labs for your own analysis and benchmark. Lets called both MariaDB Master servers as Master1 and Master2.


ice_logo-5dcea9e47b780ff52f75c3c3304d54827f56211e
Photo credits – Mariadb.org

1. Create the 2 Labs (test it on Centos7) and edit your /etc/hosts so that each server can ping each other via the hostname. On Master1, edit your /etc/my.cnf file and on the top enter the following parameter:


[mysqld]
server-id=1
log-bin=mysql-bin

2. On master1 SQL prompt, create a user for replication slave followed by flush privileges.

MariaDB [(none)]> grant replication slave on *.* to [email protected]'%' identified by 'replipassword';
MariaDB [(none)]> flush privileges;

3. Flush the tables for read-only access.


MariaDB [(none)]> flush tables with read lock;

4. At this point, if you do a show master status, you need to have a file with the mysql-bin incrementing number as well a  position number.

MariaDB [(none)]> show master status\G
File: mysql-bin.000001
Position: 612
Binlog_Do_DB:
Binlog_Ignore_DB:
1 row in set (0.00 sec)

5. Now, move on to the Master2 server, I assume you have already start MariaDB, setting up mysql_secure_installation, and edit the /etc/hosts file etc..

6. On Master2 edit your /etc/my.cnf file and on top enter the following parameter, after which you can restart the MariaDB service.


[mysqld]
server-id=2

7. Now on the Master1 server, do a dump of the database MySQL and import it to Master2, so that we make sure it starts and synchronize with the same conf. So, I did a dump of the MySQL database on master1 and SCP it to master2

[[email protected] yum.repos.d]# mysqldump -u root -p --database mysql > mysql.mysql
[[email protected] home]# scp mysql.mysql [email protected]:/home

8. On Master2 import the MySQL database


[[email protected] home]# mysql mysql -u root -p <  mysql.mysql 

9. Now, we will temporarily run Master2 as the slave.

MariaDB [(none)]> change master to master_host='master1', master_user='repli', master_password='replipassword', master_log_file='mysql-bin.000001', master_log_pos=612;
MariaDB [(none)]> start slave;

10. At this point, you would notice that the Slave is running correctly by verifying with a show slave status\G. Do check the Slave_IO_Running, Master_User, Log_Pos and the Slave_SQL_Running parameters.

11. Now that Master1 is the master and Master2 is the slave, we will perform the reverse order to reach our goal. At this level, you can unlock the tables which we did at step3. On master1 fire this command.

unlock table

12. On Master2 (which is actually a slave), re-edit my.cnf file and under the [mysqld] and server-id add the following parameter. It should look like this


[mysqld]
server-id=2
log-bin=mysql-bin

13. On Master2 restart MariaDB with the command systemctl restart mariadb and logging to Mysql and do a show master status. The result should be similar to this.

MariaDB [(none)]> show master status\G
File: mysql-bin.000001
Position: 313
Binlog_Do_DB:
Binlog_Ignore_DB: 

14. On Master1, a show slave status will prompt you an empty set. Now since we have dumped the MySQL database to Master2, we can now just run Master1 as the slave, i.e to repeat the process as in step 9. Launch this command on Master1 to create it as a slave. The File and Position should be taken from the Master2.

MariaDB [(none)]> change master to master_host='master2', master_user='repli', master_password='replipassword', master_log_file='mysql-bin.000001', master_log_pos=313;
MariaDB [(none)]> start slave;

15.  Test by creating database and tables on both servers, it will replicate on each other.

Tips:

  • Before carrying on with step1 do read the article Master-Slave database replication, as I have covered quite many issues there.
  • If you have installed a fresh MariaDB, you need to launch the script mysql_secure_installation just in the master-slave database replication article.
  • Each time you edit my.cnf file, you need to restart MariaDB so that the conf take effect.
  • After having created the Master-Slave replication at step 10, you can check on both Master1/2 with a netstat -ntpla | egrep -i established.*mysql. You would notice the established connection and the port it’s listening.
  • The command host with the IP established will also confirm its from the specific host.
  • Further testing on Master1 can also be done with command as mysql -u root -p -e “show processlist” which will give you an indication of the state of the server.
  • The value of File and Position of Master1 when using the command show master status should correspond with the values of Master_Log_File and Read_Master_Log_Pos of Master2 with the command show slave status and vice versa.