Posts

Showing posts from 2017

Ruby Blues in Openshift Origin v2 (or How I broke my app by installing new relic gem)

The day I tried to install a Ruby gem for New Relic RPM, it causes almost a day  downtime for Phusion Passenger-run Rails Application. It turns out that there are several thing that worth noting about Ruby dependency management. The First Error The error message that causes downtime is like this : Ruby (Rack) application could not be started These are the possible causes: There may be a syntax error in the application's code. Please check for such errors and fix them. A required library may not installed. Please install all libraries that this application requires. The application may not be properly configured. Please check whether all configuration files are written correctly, fix any incorrect configurations, and restart this application. A service that the application relies on (such as the database server or the Ferret search engine server) may not have been started. Please start that service. Further information about the error may have been wr

Running Pods as Anyuid in Openshift Origin

When using Openshift Origin, by default all pods are running with 'restricted' context, where they are forced to use a generated user id. Some Containers just doesn't work that way, so we need to relax the restriction a bit. Reference :  https://blog.openshift.com/understanding-service-accounts-sccs/ Creating A service account First, create a service account in your project (see https://docs.openshift.com/enterprise/3.0/admin_guide/manage_scc.html ). These are a sample yaml to do that : kind: ServiceAccount apiVersion: v1 metadata: name: mysvcacct Note that underscore are not allowed as service account name despite the official openshift example contains it. Assigning anyuid Then, a cluster administrator should login to the project and assign anyuid SCC : oc login oc project theproject oc adm policy add-scc-to-user anyuid -z mysvcacct Using the service account Now, edit the deployment config or the replication controller config to use the serv

Cleaning Openshift Origin Images Registry

Image
When using and tending an Openshift Origin cluster (for example, Origin version 3.7), it is normal to start the storage allocation in small sizes. However soon we find that storage for registry get filled up quickly with images from each build process. This post will show how to clean them up. Preparation before pruning First you need oc (origin client) binary and a user account with cluster administration capability. If the openshift docker registry  is installed inside the cluster without external access, then you also going to need OS access to one of the hosts inside the cluster. First step is to login to the cluster from your client or inside one of the hosts: oc login Prune steps Reading the documentation (https://docs.openshift.com/enterprise/3.0/admin_guide/pruning_resources.html) we find that the pruning starts at deployment, then builds, and last images. Pruning Deployment  Run this to preview which deployment are going to be pruned: oc adm prune deploy

Lessons Upgrading MySQL DB 5.1 to Percona 5.7

I just recently upgraded a database server that were previously running MySQL 5.1 (standard, Sun/Oracle version) into Percona Server 5.7. A few quirks notable enough to warrant this blog post. Planning and Preparation A Percona blog post ( mysql-upgrade-best-practices ) stated that the best way to upgrade with such huge difference in major version (5.1 to 5.7) is to do a full logical dump for all database except mysql, dump user and grants, uninstall database and remove datafiles, then install new version and import the logical dump and grants. But alas the database we are going to upgrade is so big and the IO subsystem became some sort of bottleneck when doing logical dump, our colleagues tried to do mysqldump and it tooks more than 2 days to run, prompting us to cancel the backup (otherwise it would interfere with workday application usage of the database).  Reading the blog I noted that : for major version upgrade, using logical dump  and restore dump is the safest way to

Securing Openshift Origin Nodes

Background We have deployed Openshift Origin based cluster based on  Origin Milestone 4 release. When security assessment performed on several of the applications in the cluster, some issues crop up and needs further remediation. Some issue related to application code, some others related to the openshift node configuration, which we shall discuss here. SSH issues One of the issues is SSH weak algorithm support. To remediate that, we need to tweak /etc/sshd/sshd_config by inserting additional lines : #mitigasi assesment security SSH weak algoritm support Ciphers aes128-ctr,aes192-ctr,aes256-ctr MACs hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com SSL issues The other issue is related to SSL crypto algorithms. The cipher suite 3DES is no longer considered secure, so  we need to tweak /etc/httpd/conf.d/000001_openshift_origin_node.conf (line 63) by adding   !3DES:!DES-CBC3-SHA  : SSLCipherSuite kEECDH: +kEECDH+ SHA :kEDH :+kEDH+SHA :+kEDH+CAMELLIA :kECD