2. Background
● Live in Washington, D.C.
● Software developer who has been leading a
Ruby on Rails project for over 2 years.
● Developer advocate in a Java-based world
Team Background
● 15 developers
● DoD clients in secure spaces
● Development occurs on a restricted intranet
- no way for our application to connect to the
Internet.
3. Technical Isolation?
No
● Developing on an island :o)
Yes
● Developing apps on an intranet
● No sudo privileges on servers
● Don't have control over firewall rules
6. How do we manage our Rubies and gemsets behind a
firewalled/restricted environment?
Problem 1: Using RVM
7. Solution: RVM::FW
● Created by Steven Haddox - a developer who
worked on my team and was instrumental in
our success
● https://github.com/stevenhaddox/rvm_fw
● Sinatra app that runs on a Phusion enabled
web server
● Works by modifying RVM's ~/.rvm/user/db
to point to an internal file which reference
your Rubies.
8. Set up RVM::FW
1) "rake boot:strap" to download Rubies and
packages
2) Copy contents and deploy to your internal server
3) Install RVM: "bash < <( curl http://<your-server>:<port>/releases/rvm-install-latest )"
4) Configure RVM: "wget http://<your-server>:<port>/db -O ~/.rvm/user/db"
5) "rvm reload"...and viola!
9. Using RVM::FW
● Other projects on your network can now use
your server to install RVM::FW and
maintain their Rubies.
● http(s)://[your_host]:[port]/db to get a list
of rubies. Your users can copy and paste the
contents into their ~/.rvm/user/db to point
to your RVM::FW instance to download its
Rubies.
● http(s)://[your_host]:[port]/known - will
provide a list of available Rubies when user
does "rvm list known"
11. Using Capistrano
● Not very difficult to set up, even in a
restricted environment.
● You need to set up key-based authentication,
which was my team's primary challenge.
Telnet and FTP are not supported.
● By default, Capistrano attempts to use sudo.
"set :user_sudo, false" within deploy.rb to
bypass this.
12. Capistrano
● Place chmod task in deploy.rb to chmod 775
so releases/### and releases/###/public
are accessible to Apache.
namespace :permissions do
desc "chmod the release and public folder for Apache"
task :make_public do
run "chmod 775 #{release_path}"
run "chmod 775 -R #{release_path}/public"
end
end
13. Capistrano
● Important to stop and restart Resque
workers
namespace :resque do
desc "Stop resque workers"
task :stop do
begin
run "cd #{shared_path}/path;
RAILS_ENV=production bundle exec rake resque:stop"
rescue Exception => e
puts "!" * 80
"ERROR: Unable to stop Resque workers: #{e}"
puts "!" * 80
end
end
end
14. How do we test email notifications when the SMTP
server is locked down?
Problem 3: Testing Email
15. Testing Email Notifications
● Emails blocked when being sent from
ActionMailer
● By default, ActionMailer delivery is sent to
an SMTP server running on your localhost
on port 25.
● SMTP server won't receive emails and don't
have ability to set up another full-fledged
SMTP server and configure ActionMailer to
reference it
16. Solution: MailCatcher
● Runs a lightweight SMTP server on your
localhost
● Catches any emails sent to it and displays
emails in a nifty interface.
● Configure your app to send mail to smtp:
//127.0.0.1:1025
● View emails at http://127.0.0.1:1080
19. SVN is still prevalent
● Every project on the contract used SVN
● No official server or host for Git on the
intranet.
● Git was misunderstood and misinformation
flew rapidly.
● It was difficult for people to see the benefits
of a distributed versioning control system
because of the small learning curve.
20. Solution: git svn
● Tool allows you to use Git as a valid client,
but push all of your changes to an SVN
server.
● You can use the nifty features of Git locally
(branching/merging, rebasing, etc.)
● You can use Git locally while the rest of your
team or organization uses SVN.
● It's a great tool to get your team's feet wet
with Git without having to make a complete
commitment.
21. Using git svn
● "git svn clone [SVN URL] -s" - import your
SVN repo into your local Git repo
● "git commit -am 'My awesome commit
message'" - commit locally without pushing
to the SVN server. You can do this many
times without modifying the SVN repo.
● "git svn dcommit" - Push all of your changes
to the SVN repo. Performs an SVN commit
for each one of your local commits.
● "git svn rebase" - Pull all changes from the
SVN repo and updates your local repo.
22. git svn caveat
● Remember, you're still using SVN under the
hood.
○ Rebase your work as much as possible.
○ Don't simultaneously interact with a Git repo.
● SVN history is linear
● A "git svn dcommit" rewrites your local Git
to include a unique ID. Working
simultaneously with a remote Git repo can
screw things up. Keep it simple :o)
23. Solution 2: Gitlab
● If you can host Git on a server, try Gitlab.
● Allows you to manage multiple repos. It's
pretty much your very own Github.
● You can handle user access permissions,
merge requests, issues, wikis, and code
reviews.
25. Solution: "gem server"
● Rubygems comes with the command "gem
server"
● Running this command will serve all of your
gems from http://localhost:8808
● Visiting the address in your browser will
provide gem details.
● When you install new gems, they'll
automatically be available through your gem
server.
26. Solution 2: Gem In A Box
● Provides more features, like the ability to
push gems to the server.
● Easy to set up:
○ Create the directory for storing gems
○ Modify the config.ru file to point to the gems
directory.
○ Run the server
● Push gems via the "inabox" command:
○ "gem inabox ./my-awesome-gem-1.0.0.gem"
