Sunday, January 31, 2016

Oracle Linux - configure firewalld local firewall

When using the latest version of Oracle Linux (at this moment 7) a local firewall is by default activated. The new implementation of the local Linux firewall is no longer iptables, it is currently being done by using firewalld. Using a local firewall on your Oracle Linux machine is a good practice, in some cases when you run a local test system you might not always see the direct need for a local firewall. However, in all production or semi-production situations a firewall should actually be default.

Instead of disabling the firewall when it is blocking something you can better configure the firewall to make it work. In case you run, as an example an nginx webserver, and you try to reach it from the outside you will by default be blocked. The below steps you can use to find the current firewall state and make sure you can access the webserver at a later stage in the right way. The right way in this is, opening port 80 and ensuring the rest is still secured by your firewall.

First you want to check if the firewall is running and this is indeed the issue that you cannot access your nginx webserver. You can check the current state of the firewall with the --state option of the firewall-cmd command as shown below. As you can see the firewall is running.

[root@localhost ~]# firewall-cmd --state

Now we know that the firewall is up and running we need to check which zones are currently active and on which interface they are currently active. The firewalld implementation uses zones, the default zone is the public zone. A number of zones are available by default and all have a use. The following zones are by default available in the firewalld implementation:

Any incoming network connections are rejected with an icmp-host-prohibited message for IPv4 and icmp6-adm-prohibited for IPv6. Only network connections initiated within this system are possible.

For use in public areas. You do not trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.

For use on external networks with masquerading enabled especially for routers. You do not trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.

For computers in your demilitarized zone that are publicly-accessible with limited access to your internal network. Only selected incoming connections are accepted.

For use in work areas. You mostly trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.

For use in home areas. You mostly trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.

For use on internal networks. You mostly trust the other computers on the networks to not harm your computer. Only selected incoming connections are accepted.

All network connections are accepted.

You can check which zones active with the --get-active-zones option. in the below example you will notice that the public zone is active on the enp0s3 interface. The public zone is the default zone that is loaded. For good reasons a limited number of services are activated (open) in the public zone.

[root@localhost ~]# firewall-cmd --get-active-zones
  interfaces: enp0s3
[root@localhost ~]#

Now we know that the firewall is active and that a zone is loaded, in our case the public zone on interface enp0s3 we need to check which services and ports are currently active (open). A difference between a service and a port needs to be understood to make sure you have your security tight. A service can contain one or more ports. Where a port is,.. a port. It is important to note that --list-ports will not list the ports that are covered by a service. In the example below we check the services and ports with the associated commands. As you can see no ports are explicitly open and only two services are active (open).

[root@localhost ~]# firewall-cmd --list-services
dhcpv6-client ssh
[root@localhost ~]# firewall-cmd --list-ports
[root@localhost ~]#

We stated that the example case was to open port 80 for http traffic to the nginx webserver running on the box. We can do this by adding port 80. As we want this to be permanent and ensure that this new setting is active after a reboot of the server we add the --permanent option to the command. Below you can see the example of adding and reloading the settings to ensure that port 80 will be open on the public zone.

[root@localhost ~]# firewall-cmd --zone=public --add-port=80/tcp --permanent
[root@localhost ~]# firewall-cmd --reload
[root@localhost ~]#

When we again check the services and ports we will see that the services are still the same, only two services, we do however now have a explicit mention of port 80 as an open port.

[root@localhost ~]# firewall-cmd --list-services
dhcpv6-client ssh
[root@localhost ~]# firewall-cmd --list-ports

As stated before, you have to remember that also a service is an option. In our case we open port 80 to ensure access to the http server which runs in the form of nginx on our machine. So, instead of adding port 80 explicitly we could also have added the service http instead. Adding the service http is done with the --add-service instead of --add-port option. An example of this is shown below.

[root@localhost ~]# firewall-cmd --zone=public --add-service=http --permanent
[root@localhost ~]# firewall-cmd --reload
[root@localhost ~]#

If you now check the status of the services and the ports with the commands we used previously you will notice that no ports are mentioned explicitly and http is added as a service (do note, I have removed port 80 which is not part of this blogpost)

[root@localhost ~]# firewall-cmd --list-service
dhcpv6-client http ssh
[root@localhost ~]# firewall-cmd --list-port
[root@localhost ~]#

Even though this is only a simple example of how you can configure firewalld it provides you an insight and starting point to create much more complex configurations when and where needed.

Friday, January 29, 2016

Install nginx on Oracle Linux

When you like to run nginx as a webserver, which makes very much sense if you like to run a high performance webserver which is at the same time not taking up much resources, you will have to do some additional tasks. As you might find out quickly is that Oracle is not including nginx in the mainstream repository for Oracle Linux

However, you can add the nginx repository to your local yum configuration as an additional repository. You simply need to create a new file in /etc/yum.repos.d and call it (in our case) nginx.repo 

you can use a simple touch command to do so:
touch /etc/yum.repos.d/nginx.repo

Now you will have to add the below to the content of the file. This will ensure that the nginx repository is now part of the repositories that are available when you use yum, 

name=nginx repo

after saving the file a simple yum command will ensure that nginx will be installed in your Oracle Linux system, shown below.
yum install nginx

One a number of things to remember are that, when you use a standard Oracle Linux 7 installation the standard implementation of the firewall will block port 80 for external traffic. You will have to disable the firewall or open the port. next to this you have to be aware that nginx will not be configured to start automatically when the system boots and that nginx will not be started directly after installation.

If you check the status of nginx (as shown below) you will see it is down:

[root@localhost ~]# systemctl status nginx
nginx.service - nginx - high performance web server
   Loaded: loaded (/usr/lib/systemd/system/nginx.service; disabled)
   Active: inactive (dead)

[root@localhost ~]# 

you are able to start nginx by executing: 
systemctl start nginx.service

the will ensure that the service is now up and running. If you would now check the status of nginx via systemctl you will note the following:

[root@localhost ~]# systemctl status nginx
nginx.service - nginx - high performance web server
   Loaded: loaded (/usr/lib/systemd/system/nginx.service; disabled)
   Active: active (running) since Tue 2015-12-29 01:32:14 CET; 11s ago
  Process: 2285 ExecStart=/usr/sbin/nginx -c /etc/nginx/nginx.conf (code=exited, status=0/SUCCESS)
  Process: 2284 ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf (code=exited, status=0/SUCCESS)
 Main PID: 2287 (nginx)
   CGroup: /system.slice/nginx.service
           ├─2287 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
           └─2289 nginx: worker process

Dec 29 01:32:14 localhost.localdomain systemd[1]: Starting nginx - high performance web server...
Dec 29 01:32:14 localhost.localdomain nginx[2284]: nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
Dec 29 01:32:14 localhost.localdomain nginx[2284]: nginx: configuration file /etc/nginx/nginx.conf test is successful
Dec 29 01:32:14 localhost.localdomain systemd[1]: Failed to read PID from file /run/ Invalid argument
Dec 29 01:32:14 localhost.localdomain systemd[1]: Started nginx - high performance web server.
[root@localhost ~]# 

Even though you now have a running nginx service on your Oracle Linux 7 machine you can note from the above that it is still marked as disabled. Note the last part of the loaded line in the status output which states disabled. This indicates that when the system will be (re-)booted that nginx will not be started automatically. To make sure nginx is started each time the server is rebooted you will have to make sure it is enabled. you can enable this by executing the below shown systemcelt enable command for the nginx.service which is in essence “ nothing more” then creating a link.

[root@localhost ~]# systemctl enable nginx.service
ln -s '/usr/lib/systemd/system/nginx.service' '/etc/systemd/system/'
[root@localhost ~]# 

Now you will have a running nginx http server that will start each time you will reboot your machine and you are ready to configure nginx to be used. A basic configuration can be found in /etc/nginx/nginx.conf editing this file is however not best practice. nginx.conf makes of a include /etc/nginx/conf.d/*.conf statement. This means that it is a better way to edit the file *.conf files or add *.conf files in this directory rather then editing the main nginx.conf file. 

Tuesday, January 05, 2016

Full stack monitoring for Oracle SOA suite.

Oracle SOA suite is a well used SOA server implementation in the industry. Oracle SOA Suite is a comprehensive, standards-based software suite to build, deploy and manage integration following the concepts of service-oriented architecture (SOA). The components of the suite benefit from consistent tooling, a single deployment and management model, end-to-end security and unified metadata management.

Oracle SOA Suite helps businesses lower costs by allowing maximum re-use of existing IT investments and assets, regardless of the environment (OS, application server, etc.) they run in, or the technology they were built upon. It’s easy-to-use, re-use focused, unified application development tooling and end-to-end lifecycle management support further reduces development and maintenance cost and complexity.

One of the two minute tech tips, an Oracle OTN show by Bob Rhubart, is featuring Matt Brasier who makes a excellent point on monitoring Oracle SOA suite. You can view the show below:

Full Stack Monitoring
A good practice is to not monitor only SOA suite itself, monitoring the full stack will bring you the full value. Only monitoring the working and performance of SOA suite will only give you a hint of what might be wrong and where an issue might reside. Also, by only monitoring Oracle SOA Suite you will also be less able to predict issues before they happen.

Instead of "only" monitoring SOA Suite you should monitor the full stack, this includes (among other things):

  • Network
  • Server hardware
  • Storage
  • Oracle Linux Operating System
  • Weblogic Middleware
  • JVM (Java Virtual Machine)
  • Oracle SOA Suite (health)
  • Oracle SOA Suite (Response times)
  • Database connections / database pooling

Oracle Enterprise Manager
When you want to monitor your solution in a full stack mode and ensure you can provide the best services and uptime to your users you should consider how to implement monitoring in your organisation. As you are using Oracle SOA suite you will most likley have more Oracle components in your IT footprint, using Oracle Enterprise Manager base functionality plus additional packs where needed is then a logical decision.

Oracle Enterprise Manager (OEM or EM) is a set of web-based tools aimed at managing software and hardware produced by Oracle Corporation as well as by some non-Oracle entities.

Deploying Oracle Enterprise Manager will bring you exactly what is needed for a full stack and end-to-end monitoring, alerting and maintenance solution. As it is developed by Oracle it will by nature be able to communicate in an optimal way with the Oracle products, this includes not only SOA suite and the Oracle Database, this also includes the operating system Oracle Linux for example and extends also to the Oracle hardware and the network.

When you want to provide optimal monitoring and maintenance to your Oracle SOA suite implementation it is best practice to monitor the full technology stack. The solution provided by Oracle is Oracle Enterprise Manager which provides a lot of free to use features and can be extended with custom checks or additional packs when needed.