Monday, September 4, 2017

Firewall Blocked Github: Connection refused

When I am at work, I encountered the following error while attempting to access Github,

ssh: connect to host port 22: Connection refused
This could be the result that the corporate firewall blocked the SSH service (TCP port 22). In this case, we can inform the ssh client to use port 443 instead according to this Stack Overflow post. To do this, we add the following configuration for the ssh client,

cat >> ~/.ssh/config << END

  Port 443

For me to use ssh to connect to Github, the Github official documentation turns out to be very helpful.

Tuesday, August 29, 2017

Running Out-dated JNLP Program

When attempted to launch the remote control JNLP Web Start program from a computer server, I encountered an error:

Unsigned application requesting unrestricted access to system
The following resource is signed with a weak signature algorithm MD5withRSA and is treated
as unsigned:

The screen shot is also included,

The error is the result that Java has updated and the MD5withRSA should not be used any more. One work around is to temporary enable the MD5withRSA. One may change the Java security configuration by editing the file. In my case, the file is C:\Program Files\Java\jre1.8.0_141\lib\security\ You will find a line that disables a few algorithms, such as,

jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024

We can now simply comment out the line by adding a # at the beginning the line. The line should become,

#jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024
In addition, you may need to launch the Java Console, and add the site, in my case, in the "Exception Site List".

Monday, August 28, 2017

Finding a Disk's Serial Number in FreeNAS

When a harddisk pool in FreeNAS encounters many errors, FreeNAS would report errors. In this case, we need to figure out which physical disk may have problem. The following steps help us find out serial numbers of the disk,, in conjunction with the BIOS information, we may figure which physical disk has problem.

# show a list of disks with their GPT IDs
zpool status
# show the mapping beetween GPT IDs and device names
glabel status
# from above two steps, we can know which physical device may have 
# problem, e.g., /dev/ada5p2
sudo  smartctl -a /dev/ada5 | grep "Serial Number"

Friday, August 25, 2017

SeLinux Setting for Mercurial Web Access

If you use the Mercurial Revision Control System or HG, you may set up a Mercurial CGI Server integrating with a HTTP server, such as the Apache HTTP server so that you can provide read and write access via HTTPS.

The Mercurial official website provides a well-written documentation for this. However, you may run into the 501 Internal Server Error when you try to browse the repository via the Web or encounter the 500 Permission Denied Error when you try to push your local changes to the remote Mercurial repository via the HTTPS protocol. These errors often occur when you have SeLinux enabled.

The following provides a simple script to set up the proper SeLinux context for Mercurial repositories.

Assume the parent directory of all your Mercurial repositories is in the environment variable HG_PARENT_DIR, the Apache HTTP server is run as user belonging to group stored in environment variable HTTP_GROUP, and you wish the user whose username's value in environment variable HG_USER to manage all your Mercurial repositories. You can set up the proper SeLinux context using the following commands on a Linux shell by initially assigning hguser, apache, and /home/hg to environment variables HG_USER, HG_GROUP, and HG_PARENT_DIR.

chmod -R ug+rw  $HG_PARENT_DIR$
chcon -R -t httpd_content_t $HG_PARENT_DIR$
find $HG_PARENT_DIR$ -name .hg -exec chcon -R -t httpd_sys_content_rw_t {} \;
find $HG_PARENT_DIR$ -name \*.cgi -exec chcon -t httpd_sys_script_exec_t {} \;
The above script does not give the HTTP Web server process any more permissions than necessary, but does give and confine the required permissions to your Mercurial repositories.

Tuesday, August 15, 2017

Getting SSL Certificates Using ACME Clients

Previously I discussed the growing importance of SSL and HTTPS, in particular, how they may help protect user privacy. To run an application that supports SSL or HTTPS, one must obtain a SSL certificate. Although SSL certificates have become less costly and some vendors even offer free SSL certificates, there are still a few barriers for many users, such as, a user still needs to manage renewal, suspension, and installation of SSL certificates, and very few vendors provide free SSL certificates. Recently, the development of "Automatic Certificate Management Environment (ACME) protocol" has made the adoption SSL or HTTPS and acquiring SSL more easily.

The following example demonstrates the steps to use an ACME client, the certbot to acquire and install certificates for an Apache HTTP Server instance at a CentOS 7 system.
  1. Install CentOS 7
  2. This step and the steps that follow are done at the CentOS 7 system. Install Apache HTTP Server with mod_ssl.
        sudo yum install httpd mod_ssl
  3. Enable and start the HTTP service.
      sudo systemctl enable httpd.service
      sudo systemctl start httpd.service
  4. Enable the EPEL repository.
      sudo rpm -ivh
  5. Install certbot, an ACME client from the EPEL repository.
       sudo yum install certbot-apache
  6. Acquire SSL certificates from "Let's Encrypt", and install them at the Apache HTTP server.
      sudo certbot --apache
  7. The certificates are set to expire in 90 days. Therefore, we need to set up an automatic renewal, which can be done either in a systemd/Timers or a cron job. Below is a cron job. However before proceeding to schedule a renewal job, we can test the renewal via the following,
      certbot renew --dry-run
  8. We now schedule the renewal job twice a day as advised by the "Let's Encrypt" site.
    "If you're setting up a cron or systemd job, we recommend running it twice per day (it won't do anything until your certificates are due for renewal or revoked, but running it regularly would give your site a chance of staying online in case a Let's Encrypt-initiated revocation happened for some reason). Please select a random minute within the hour for your renewal tasks."
    Following the advice, a cron job runs twice is added via crontab -e as root.
      0 5,17 * * * /bin/certbot renew > /var/log/certbot.log 2>&1
  9. To test your HTTPS site, you may use SSLLab's service. For instance, if you site is, you can point your browser to

Except the certbot, there are many other ACME clients. See the Let's Encrypt site for a recommended list.

Monday, August 14, 2017

Does My Internet Service Provider Block Port 80?

If you are like me who runs a little web server at home, you may encounter this problem, that is, regardless how you try, you simply cannot get port forwarding to work for port 80 while port forwarding functions fine for any other ports at home. It turns out that I am not alone. For instance, this Linux Questions thread states,
"Turns out Cablevision (my provider) 'blocks' port forwarding on their routers, so they say."

Yes, and indeed, that is what they say. My current Internet Service Provider (ISP) is Optimum. It states on their customer service site,
"Because Port 80 is often used by malicious software, including viruses and worms, Optimum, like many ISPs (Internet Service Providers), blocks this port for all standard Optimum customers."
Fortunately, it also provides a solution in the same page,
  1. Go to
  2. Sign in with your Optimum ID and password
  3. Place your cursor on and click the 'Internet' header
  4. Under 'Port Configuration' click on 'Settings'
  5. Under Port 80, click on the slider to turn On or turn Off.

This post serves as a reminder that you may want to check with your ISP if you struggle to get port forwarding to work for port 80 at home, and it may save you a few hours.

Setting up no-ip Service on Fedora Linux 26

It is simple to set up the no-ip dynamic DNS service. The steps are as follows,

$ sudo yum install noip
$ sudo noip2 -C
$ sudo systemctl enable noip.service
$ sudo systemctl start noip.service

In the above, the first step is to install the noip client, the second step is to configure the noip client, the third step is to enable the noip service, and the last step is to start the service. Since the service is enabled, when the system is rebooted, the noip service will be automatically started. One important reminder, do not forget to create your domain name at noip.