[Solved] Install Hipchat 4 on Fedora 23

Hipchat has documentation for installing on Debian-based distros but not on RPM-based distros like Fedora and RHEL.

However, there is an undocumented repository for RPM. The undocumented RPM repository is: https://atlassian.artifactoryonline.com/atlassian/hipchat-yum-client

To install the repository:

Next, to install Hipchat 4:

SSH Tunnel Local Port to Local Port on Remote Machine

Reducing your attack surface is an important part of network security. If you are running a service that only needs to be accessed from localhost, you should not allow connections from the outside world. On my web servers, only 3 ports are open:

  • 22 for SSH
  • 80 for http
  • 442 for https

All other ports are filtered. This significantly reduces the number of possible attack vectors. Other services such as MySQL (port 3306) are only accessible from the private network. To access MySQL from a remote machine you can SSH tunnel to the database server and then connect to the database on localhost. Most database clients like MySQL Workbench support SSH Tunneled Connections.

However, I came across a problem when I wanted to run a python script locally to update my remote database server. There is a library for connecting directly to a MySQL database with Python, but not for connecting through an SSH Tunnel. Another option would be to run the python script on the remote server, but in my case I did not want to do that.

To solve this, we will have to manage the SSH Tunnel ourselves. After building the SSH Tunnel, you will be able to connect to a port on your local machine and the connection will be sent to a different port on the remote machine’s loopback interface.

If you use key authentication to SSH, run this command:

If you are using password Authentication, run this command:

That’s it. The command will go to the background and you can connect to localhost:1234 as if it were locahost:3306 on the remote server.

Final Notes

Test the SSH Tunnel

There are a few final notes when using this command. First, to test that your tunnel is working, try to connect to MySQL on the remote server by running this command on the local machine:

You must to set the host (using the -h flag) to 127.0.0.1. If you leave the host blank or set it to localhost, MySQL uses sockets and thus ignores the port flag (-P).

Close the SSH Tunnel

How do we close the SSH Tunnel? When you want to destroy the SSH Tunnel you can run the following command. It will kill a process that is listening to port 1234:

Keep SSH Tunnel Alive

Finally, when using SSH Tunnels you may want to configure  SSH to keep the session alive so your connection does not drop unexpectedly. SSH does not close connections after any length of time, but router’s remove inactive connections from the NAT tables periodically. To prevent this from happening, add the following code to the top of your SSH configuration file:

Adjust ServerAliveInerval  and ServerAliveMaxCount  as desired. SSH configuration file is found in  ~/.ssh/config

[Solved] Change httpd Document Root results in 403 Forbidden on Apache 2.4 and Fedora 22

Recently, I decided to take the leap and begin using Linux exclusively. I installed Fedora 22 and so far I like it. I hit my first major snag when setting up a LAMP development environment.
After installing Apache and setting up a virtual host all pages returned error 403 Forbidden. I am running Apache 2.4. The first thing I noticed is that Apache changed the syntax for allowing and denying access to a directory. Previously you would use:

to grand access to a directory. In Apache 2.4 you use:

After ensuring I was allowing access to the new document root in httpd.conf correctly, I started to get stuck. Only after much digging, I came across the root of the problem: SELinux Contexts. SELinux adds an additional level of security by layering more flexible and powerful access controls on top of the standard Linux access control. SELinux is found on Fedora and Red Hat systems.

You can check to see if SELinux is enforcing access control on your system by running:

You must add the httpd_system_context_t context to the new document root so that Apache has access. You can read more about SELinux here.

In production you do not want to weaken security to get things working. You should give files the correct context so Apache works with SELinux. However, in a development environment, you can simply disable SELinux to make your life easier.

To disable SELinux modify /etc/selinux/config to look like:

Save that file then restart. You can run sestatus again to make sure SELinux is disabled. If you configured httpd.conf correctly, Apache should now be able to access the new document root.