Enable OpenVPN Management Interface on ClearOS
The OpenVPN config file structure on ClearOS is non-standard (For example there is no server.conf), so I was unsure where to put the directive. However, as it turns out enabling the Management console is as simple as adding the following to /etc/openvpn/clients.conf:
management localhost 7505The port is arbitrary: any unused port will do. Localhost restricts connections to the local machine, which is smart if you do not have a password to secure the connection.
To access the management interface using telenet, issue the following from the clearOS box:
telnet localhost 7505 #When the prompt comes up, issue a command such as "status"
Doctrine And ORM Designer
Edit: Shortly after positing this entry, Inventic contacted me with some responses. These are in italics.
I’ve been using Doctrine in conjunction with the Zend Framework for years. Although it is an excellent ORM, writing yaml by hand is a tedious and error-prone process. Furthermore, it can be difficult to visualize a large database from a series of text files, so I find myself maintaining a MySQL Workbench diagram in addition to the textual database representation.
ORM Designer promises to change all that. It brings a visual database editor for Doctrine 1 and 2 that reduces effort, mistakes and increases productivity. Migration from my existing workflow was a snap due to the import functionality: I had the option to import both my yaml database definitions as well as my MySQL workbench files. The ability to break up the data-model into individual modules keeps the code clean and organized, and the export functionality, in conjunction to the external tools integrate yaml generation and Doctrine CLI operations directly into ORM Designer’s interface.
ORM Designer Features for Doctrine Users:
- Behaviour Support
- Versionable
- Timestampable
- Sluggable
- I18n
- NestedSet
- Searchable
- Geographical
- SoftDelete
- EventLoggable
- GoogleI18n
- Sortable
- Blameable
- Taggable
- Inheritance Support
- Many-to-one, Many-to-many relations
- Index support
- yaml Generation
Extendability:
- Creation of new ORM Properties & data-types
- Creation of new behaviours
Support and Releases
The folks at Inventic crank out a new version of ORM Designer every few months. There were around 16 releases in 2010, but development seems to have slowed slightly with only three releases to date in 2011. On the whole, with both bug fixes and feature updates, you can still expect good value for the 1 year upgrade maintenance that is included in the purchase price.
ORM Designer is currently very stable and as such doesn’t require many bug fixes. The team is currently putting most of their energy into ORM Designer 2 which is slated for a public beta around the end of 2011. However, there are 1.x beta releases available at http://www.orm-designer.com/beta which contain new features and bug fixes as they become available.
The forums are a little thin, which may be simply because the software is relatively new and is still being discovered. However, it appears that user posts commonly receive a same-day reply from the developers. Users can really take advantage of the small community and direct access to developers to suggest features and shape future directions of the software.
My Wish List
Although ORM Designer supports modules I would like to see this area further developed. For example:
Say you have a common user module stored in a common SVN location (Eg: SVN External) that you would like to use with every project, the ability to link the common module, add relations / properties (without affecting the original module) and export the module relative to the current project’s path would be excellent additions to ORM Designer’s feature set.
Inventic suggests pulling in modules directly into the application (at the appropriate path) using SVN Externals rather than having a more libary-like directory structure
Conclusion
ORM Designer provides excellent value for anyone who uses either Doctrine or Propel. The ability to visually edit data models for these ORMs brings them on par with the nHibernate framework in terms of usability.
ORM Designer also supports the Doctrine2 and Propel ORM’s as well as the CakePHP and Symfony frameworks.
ORM Designer is designed for windows, however it can run under WINE for Linux/OSX support. However, ORM Designer 2 is currently under development and makes use of QT rather than MFC which will bring native support to the other operating systems.
Jenkins CI Slave on Ubuntu 10.04 Lucid LTS Howto
Posted by Dustin in How-To, Linux, Uncategorized on June 18, 2011
Install Sun Java:
sudo add-apt-repository ppa:sun-java-community-team/sun-java6 sudo apt-get update sudo apt-get install sun-java6-jdk
Ensure a SSH server is installed
sudo apt-get install openssh-server
Create a new Jenkins user and create the /var/jenkins directory – this will be our working directory.
sudo useradd -m jenkins sudo mkdir /var/jenkins sudo chown jenkins:jenkins /var/jenkins
Generate a public / private keypair and set the public key as an allowed host
ssh-keygen #Enter file in which to save the key (/root/.ssh/id_rsa): /var/jenkins/private.key #Do not enter a Passphrase #You should now have two files in /var/jenkins: a private.key and a private.key.pub, we want to cat the public key into our authorized keys file su jenkins cat private.key.pub > ~/.ssh/authorized_keys
The private key must be transfered to an accessible directory on the primary build server. Eg: C:\private.key or a more suitably protected location.
Login to your Jenkins install, select the plugin manager and install the SSH Slaves plugin. After restarting Jenkins to complete the install, click on Manage Jenkins followed by Manage Nodes and create a new dumb node with a name of your liking.
Configuration parameters:
Remote FS Root: /var/jenkins
Launch Method: Launch slave agents on Unix machines via SSH
Host: <Ubuntu Hostname>
Username: jenkins
Private key file: File of the private key (eg: C:\private.key)
When you press save, the slave should attempt to start automatically. If the start fails, check the log provided by jenkins and the server log.
Remote Debugging With Firebug and Cometd
While experimenting with mobile development on the Blackberry Webworks Platform I found that it was extremely difficult to get any debugging information out of the device simulator to help debug javascript errors.
The Webworks Eclipsed-based IDE does provide limited debugging support; however, I found the OS5 device support for javascript to be extremely lacking (Especially while using the Dojo library) and Webworks is currently unable to debug OS6 devices.
At a bare minimum I wanted my familiar firebug console.* calls to show up somewhere I would be able to see them. Although this is far short of a full remote debugging solution (such as the Firebug Crossfire Project), it would at least allow me to see what is going on under the hood.
Implementation Overview:
- A Small javascript file is included on the mobile page. This file adds additional console methods and, optionally replaces the default console.* debugging methods
- A CometD provides communication between the mobile page and the page that firebug is listening on
- A special listening page is setup where the debugging events coming over the cometd server are passed onto firebug
Prerequisites
For my development environment I am using Eclipse 3.6 with the Maven tooling installed. Maven is used so the CometD API can be easily utilized. For more information about building CometD applications with Maven please see the CometD Primer. Maven is also nice as it will download the required dependencies (such as the Jetty Server).
Getting & Compiling the Source
- Please clone my GitHub Repository to obtain the source code. This can be found at https://github.com/51systems/Remote-Console
- Import the project into eclipse
- When you are cloning the repo it is most convenient to clone it into your eclipse workspace directory, this makes importing into eclipse easiest
- In Eclipse Choose File -> Import
- Scroll down and roll open the Maven import source
- Choose Existing Maven Projects
- Locate the cloned repository & Select the pom.xml file for import
- Maven will now download dependencies and attempt to build your project. This may take time so be patient
At this point, you should have a built remote-console project in your Eclipse workspace. You will find that there are two separate source directories: One contains the java source and the other contains HTML & Javascript.
The java source folder is uneciting: it contains the bare-minimum vanilla implementation necessary for the CometD server to pass messages between the mobile device and the firebug page.
The HTML / Javascript source folder contains some example pages + the remote-console.js file which, together, provide the remote-debugging functionality.
Running the Server
To run the Jetty server for the first time:
- Create a new Maven Build Run-Configuration
- Can be done by right clicking on the remote-console project and choosing Run As -> Run Configurations or by rolling out the run icon
- Ensure the base directory is set to the correct workspace directory. Mine is ${workspace_loc:/remote-console}
- For the Goals text box enter “jetty:run” this will start the jetty server
- Can be done by right clicking on the remote-console project and choosing Run As -> Run Configurations or by rolling out the run icon
- Start the Jetty server by clicking Run in the configuration dialog
- You should see console output in the Eclipse window. Inspect this output to catch potential problems
- Visit http://localhost:8080/remote-console/ to view the remote-console application.
Remote Debugging
When you visit the remote-console application link you will be presented with the remote console connection page. This page allows you to connect to a remote console on a specific channel and have the debug messages appear in a firebug window.
There are two types of demo pages. The default one uses dojox.json.ref to serialize objects. This allows for the serialization of javascript objects that have circular references. The second demo page serializes objects using the default json serialization – be careful with those circular references with this one.
To Use remote debugging for the first time:
- Start the firebug listener:
- Visit the Remote console connection page with firefox
- Open The firebug console
- Click the connect button to connect to the default local cometd server
- You should start seeing the long-polling entries appearing in the firebug console
- Visit one of the demo pages, either in a new firefox window, or using another browser
- Use the console.log textbox and button to send a console.log message to your listening firebug console.
- You should see the logged textbox contents appear almost immediately in the firebug console log
- Next steps:
- On one of the demo pages, try a more complex debug expression, such as
console.log("test", {foo: "bar"});
- You should see the message and object quickly appear in your listening firebug console.
If you are using the dojox.json serialization you may see additional fields on the object when it is displayed in the firebug console.
- On one of the demo pages, try a more complex debug expression, such as
Adding remote debugging to your own pages is as easy as adding the dojo library and the remote-console script tag to the page you wish to debug.
<script src="http://ajax.googleapis.com/ajax/libs/dojo/1.6/dojo/dojo.xd.js" type="text/javascript"></script> <script src="remote-console.js" data-server="http://127.0.0.1:8080/remote-console/cometd" data-channel="demo" data-json-ref="true"></script>
Ensure that the src path is set correctly to point to the remote-console.js on the jetty server. Likewise the data-server attribute should point to the server and path running the jetty cometd implementation. Pay attention to the loopback device IP and be sure to change it if you are planning on debugging on another device.
There are several parameters that you are able to pass to the remote-console.js script via HTML attributes. Please view the ReadMe in the Git Repo or the source code for a complete list.
WebWorks Resource Name Not Valid Workaround
I’ve been looking at using Phonegap and Dojo for rapid application development on mobile devices. As I have been doing blackberry development for the past year or so I thought that this would be a good platform to start on. However, I almost immediately ran into a problem with the WebWorks packager.
The problem is that the packager will not permit paths with special characters in them – special characters including the somewhat limiting “_” and “-”. Instead of packaging the files it would return the error Invalid widget archive – resource name is not valid This is especially a problem with dojo and it commonly uses these conventions for stylesheets and js files.
After Googling, I found that this behaviour was by design. It seems that if you pass a file with a dash in it, the RAPC compiler thinks that it is a command line switch.
See:
https://www.blackberry.com/jira/browse/WEBAPI-50
http://supportforums.blackberry.com/t5/Web-Development/bbwp-quot-resource-name-not-valid-quot/m-p/607222
http://mobijournal.com/common-blackberry-webworks-development-pitfalls-that-can-be-avoided/
Fortunately, RIM has recently open sourced the Webworks API. I knew from my experience with bb-ant-tools that you were able to pass a file containing paths to the files to include in the package, thus circumventing the problem with the command line switches.
The packager now successfully packages _bad-path.txt.
To patch your webworks packager, download WebWorksPatched extract it and move the bbwp.jar to your webworks bin folder (Usually C:\Program Files\BlackBerry WebWorks Plug-in Eclipse\plugins\net.rim.browser.tools.wcpc_1.5.1.201010291444-22\wcpc\bin).
For the brave of heart, source code is available on GitHub at https://github.com/51systems/WebWorks