After 2 years at the kudelabs office, gzruby has outgrown our humble common room. We have decided to move to a new venue - one with more space, and we think it will be a lot more fun! As always, gzruby is about getting a bunch of people together to talk about what we all do for a living. Its a chance to learn from each other, and find ways to improve our craft. If you are a ruby developer who has never attended, its like finding a new group of friends that you never knew you had.
View the invitation at the gzruby home page
The new venue is close to our office, close to Zhu Jiang New Town, and features hand-crafted beers made by one of Kudelab's former interns!
We take our summer internship program very seriously at Kudelabs. Guangzhou has wonderful universities with hundreds of very qualified graduates every year. This year we posted 2 openings, and we're proud to announce that they have been filled. We'll be welcoming our new interns soon!
Every once in a while we just need to get away from it all, and that's what we did! The whole Kudelabs team took off from Guangzhou for 3 days to the amazing Camiguin island just off the coast of Mindanao. Getting there was no joke: 2 flights, a 2 hour jeepney ride, and a 1.5 hour ferry ride later we were finally on the island.
Camiguin is an absolutely magical place. Over 3 very busy days, we snorkeled with meter-long fish, swam at the base of a 75m waterfall, hiked 10 hours over the top of an active volcano, and watched the sun set from a black sand beach as children of fishermen played in the waves around us. I won't even start on the food.
By the time we got back to Guangzhou, we were super tired, but ready to get back to work! Thank you Philippines for an amazing adventure!
GZRUBY10 will be held at the Kudelabs offices this wednesday evening, starting at 7:30. GZRUBY is a gathering of ruby developers, Kudelabs is one of the sponsors along with other ruby development companies in the city. Its always a lot of fun and a great chance to meet up and talk web development. Find out more at the Guangzhou Ruby Group page.
StartupGrind is a global network of startup communities that was established to educate, inspire, and connect entrepreneurs in the city. Here in Guangzhou, we see it as a way to connect the English speaking world with the Chinese startup ecosystem. The second event features founder Clement Song, who founded eCitySky and successfully completed an acquisition to YY Inc. He's now with YY as the Directory of Platforms and Services, and was able to experience an IPO first hand. Find out more at StartupGrind Guangzhou Meetup page.
Kude Labs (酷德实验室) is a growing software development firm focused on building high quality web applications. Our office is located in Guangzhou Wuyang District (广州市五羊邨).
We are happy to offer internship positions for students looking to improve their skills and gain some practical experience working on real-world projects. Intern positions are part time and can transition into a full time position after graduation. The majority of our full-time employees joined our team first as interns.
Software Testing Intern - Web applications
We are looking for smart Quality Assurance engineers for testing the Web Applications we develop.
Ideal candidates would have:
- Outstanding analytical thinking abilities
- Patient and precise work style
- Major in Computer Science or Mathematics related studies
- Experience with open source tools
- Excellent written and oral communications skills
- Self motivated and able to work independently
- Nonjudgemental, welcoming attitude
Please send an ENGLISH letter of interest, references and resume to: firstname.lastname@example.org.
We look forward to working with you and welcoming you as a part of the Kudelabs family.
See more internship and full time positions at GZTechJobs.com
The 9th gzruby meetup will be coming to the kudelabs offices in Guangzhou next Wednesday, November 21st at 7PM. We'd love to see you there! You'll meet several members from the growing Ruby community in our city, and have a chance to present an idea you're working on or a gem you use. Feel free to invite anyone who may be interested in ruby, or learning more about Ruby on Rails.
gzruby is the Guangzhou Ruby User's group, we meet once every 2 months to share tips and techniques, as well as show off recent projects.
Given the problems passwords pose, isn't it time to offer people a second authentication factor? Your bank does it. Google does it. Even games do it. You can too. How hard is it to get Rails set up with a one-button six digit authenticator? Not hard at all! The hardest part was knowing where to look and what to get.
Close inspection of the dongles we already have revealed one name printed on them all: VASCO. VASCO provides the physical token you hold in your hand. We ordered a few of these. VASCO also provides the server software to authenticate tokens. The software comes in all sizes: enterprise, cloud, but for us the perfect match is just a C API called the VACMAN Controller. It runs on Windows, Linux, some more exotic OSes, but not Mac OS X.
How does it work? Each token has a serial number and contains a clock. When you press the button, the token shows a six digit one-time password based off that clock. Send the serial number, the password, and a little magic to the C API. It returns whether everything matches up right now. (So the clock on your server better be on time.)
How does the C API know whether the serial number and password match? In the beginning, VASCO creates a special encrypted file for you. It records how the clock and the serial number are synchronized. Before anyone can use their tokens, you have the API import the special file. It returns a data-structure with authentication information. Pass this magic struct with the serial number and password when authenticating. After authenticating, the data-structure is updated. Besides simple statistics like number of successful authentication attempts, the data structure stores information about token's internal clock. This allows the API to compensate for gradual time drift. The API itself is stateless. It's your job to keep track of the tokens and the data-structure.
Okay, but how does it work with Rails? As always, apply a little bit of glue. SWIG makes wrapping C APIs easy. This time was no exception though we did need to do a little more to allocate and free data-structures than usual. For the database, use ActiveRecord if that's your thing. We went with Sequal. We used two tables:
- One table maps user names to token ids.
- The other table maps token ids to magic data-structure blobs.
That's it really. We just use a script to import the import the token info. We don't use enough tokens to try to automate further.
Summer in GZ brings some really hot weather! But it also brings tremendous rainstorms, clear skies after the rain, and excellent fruits. We currently have a blooming starfruit tree. I hope it is able to bear fruit later in the season.
Rails 3.X doesn't have the textilize and textilize_without_paragraph helper methods. Textilize is a gem brings back the missing method for Rails 3, and it includes the library RedCloth 3.0.4, which doesn't need to be compiled on server. Btw, The newest RedCloth is currently at 4.X though, it requires compiling C extension.
The reason we need this gem is that we use :textilize at a few places in our apps, and we don't need super fast RedCloth, we just need a working version that don't force us to install C extensions on various production servers. This could be useful for bundle-package usage, where you can rely on the bundle/cache gems.
In the course of our work we have come across a variety to linux flavors; RedHat Enterprise Linux, Ubuntu, and CentOS seem to be the most common. Lately I had to get a new CentOS box set up with a typical Rails stack, ruby, rvm, Passenger, mysql and so on.
There are plenty of articles that describe how to install the stack, and since the commands change constantly I won't bother with rehashing this. What I want to describe is how to make sure your Passenger app can be run on a locked down SELinux box safely.
The first thing to consider is what SELinux does. It is designed to combine all the best practices on server security and turn them ON by default. In fact, the only port that will respond to traffic is port 22, so that you can ssh in. Everything else is shut down.
Opening the Firewall
So the first thing we need to do is open things up a little bit more, specifically, we'll want to make sure outside people can access our web site, so lets open port 80 for http traffic. On CentOS, the system firewall is handled by the service
iptables and configured in the file
/etc/sysconfig/iptables. You can enable traffic on port 80 by adding this line to your iptables config file:
-A INPUT -m state –state NEW -m tcp -p tcp –dport 80 -j ACCEPT
However, you need to make sure to add this line before any REJECT lines, as the rules are read in order and any REJECT directives will override later ACCEPT directives. Once you have saved the file, you need to restart
$ sudo service iptables restart
Another difference between Ubuntu and CentOS is that CentOS requires that your application directory, and all parent directories, have absolutely the right permissions. To accomplish this without
chmod 777 -R * (please don't do that). I like to set up my groups and users carefully. First, off, I have a user that is in charge of logging in and managing the apps. Lets call her releng (release engineer). On the server, I use the
/srv dir as it is at root, and has nothing inside. I add an apps dir, then set up my app inside of that, so I have a path like
/srv/apps/appsauce (my new app is called appsauce). I then create a symlink
ln -s /srv/apps /apps so that in all scripts and config files, I can simply use
Now, we want to make sure releng has access to all these files, so we run
chown -R releng /srv. But the apache user needs access to these files as well! So I like to add apache to releng's group:
usermod -G releng apache. Now that means we need to make sure the group releng has access to all these files. So we can run:
chgrp -R releng /srv. At this point, we have a human user and a process user in the same group, accessing the same directory tree under
If you are used to Ubuntu and simply install passenger right away without taking a breath, you probably will run into some trouble. If you check the httpd error logs (
/var/log/httpd/error_log) you'll see that passenger is complaining about permissions. It seems that passenger is not allowed to do something it really needs to do. In this case, create files in the tmp directory.
In SELinux, not only are the ports shuttered, but the file permission structure is very strict. The apache user that is running passenger is not allowed to access files or directories it does not create itself, unless specifically given permission at the system level. Giving the apache user this access is a process I won't get into here. Luckily enough, there is a way to create permissions based on how an application is used. This article explains how to properly add permissions for passenger. The idea is to turn off SElinux, run the app, then turn the log of what the app asked for permissions-wise into a permissions policy for that app. Once the correct policy is in place, you can turn SELinux back on and run your app securely.
The article is missing an important piece of information though. If audit2allow has not been installed on your system, you won't find it in the yum repositories. You'll need to install the package
At this point, we should be able to run our app with SElinux turned on, and only port 22 and port 80 open for connections. This is a rock solid platform for your product or your clients applications. Leave a comment if you have any improvement suggestions.