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.
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.
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.
3. After some minutes, it would log in automatically on the GUI interface. You also choose your ISO as per your best desktop environment.
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.
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.
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.
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.
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:
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.
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
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 get head
rvm get stable
6. You can check if all dependencies are installed with the command
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
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.
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.
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.
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.
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
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.
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 220.127.116.11
;; ANSWER SECTION: google.com. 173 IN A 18.104.22.168 google.com. 173 IN A 22.214.171.124
6. This section acts like a stat section. Information is given about the time it takes to query. The server IP address i.e; 126.96.36.199 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: 188.8.131.52#53(184.108.40.206) ;; WHEN: Sun Nov 08 01:19:23 EST 2015 ;; MSG SIZE rcvd: 204
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.
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:
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
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.
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
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.
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
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.
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.
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.