In 2004 I started working with multiple FreeBSD servers for multiple clients, that needed to be administered by non-admin users. I know you are saying “you idiot” and “why would a non-admin user need to administer the server?” I was hired as a consultant and they wanted to be able to add users, web hosts, databases and dns entries more easily than remembering all the little things that were needed. I didn’t trust WebMin at the time due to being hacked several times prior. In response I wrote Unix::ServiceConfig which I hooked up to a perl script as a way to help me with allowing the non-admin users to more easily manage the server.
It worked really well at it’s job, and the users were happy. I haven’t updated the code since 2008, and it is primarily FreeBSD centric. But I figured it is better to release it now, than to never release it. It is under the MIT license.
The other day the COO, a co-worker, and I were talking about things happening at the Company, and a quick side trek into the value of IT certifications came up. My original stance on the subject was that certifications weren’t valuable and that the skills we end up sharpening are better. After talking with them though I came to find out that not all certifications are created equal, some have more value than others. I don’t have all the answers to what the best measures of how to find those valuable certifications, but I did think about it longer, and I believe I’ve come up with something to help us measure wither getting a certification is worth it.
Recently I had to upgrade a server from a Debian 4 to Ubuntu 14.04LTS. One of the problems I encountered was that freeradius behaved badly when I ran
service freeradius reload. Mainly, I would end up with a lot of failed binding logs, because upstart had no clue how to reload the process. It turns out that that upstart script is misconfigured.
I’ve recently been converting some VMWare Fusion VM’s to VirtualBox and part of that process I had to re-remember how to do after having done it before. This serves as my memory, and some documentation, on how this is done.
With the release of jQuery 1.9 using .toggle() as .toggle(handler(eventObject),handler(eventObject)) was deprecated and removed. Last year one of my clients needed to use this functionality as they had other triggers happening at the same time as the content being shown or hidden. To assist with the upgrade I wrote a plugin for jQuery called ToggleEvent that does something similar to the old .toggle() syntax. Just recently I upgraded another one of my work projects to jQuery 1.11.0 and I forgot about the loss of .toggle() being used this way. Luckily I remembered that I had solved the problem before and dusted off the ToggleEvent plugin.
Realizing that I had forgotten to both write about the plugin, and publish it, I have now done so at github: jQuery ToggleEvent plugin
Recently I was testing a function that generated slugs for an application. In order to make the slugs unique we would append the microtime to the slug if needed. After updating my data provider to account for using the microtime version of the slug I was receiving intermittent success for the test cases. Using microtime for generated data introduces a margin of error into the time between when the code is executed and when you compare the results.
I tried using microtime before and after the function call that generated the slugs, but I would still end up around ~0.0010 seconds behind the microtime that the slug generator was using. I could not figure out how to make these tests pass 100% of the time, within reason.
If you can’t control the generator for tests that involve random data you have 2 options:
- refactor to remove the randomness
- live with a degree of certainty
For the purposes of generating a slug with appended microtime, I determined that the degree of certainty was that the slug’s microtime at the seconds level will either be equal to or at most one second before the microtime of the test cases microtime call. If it is greater than 1 second difference then there is definitely a problem. The 1 second threshold could most likely be reduced (for example to 0.0010 seconds) if desired, but I needed to get the test written in a timely manner and a 1 second degree of certainty was acceptable at the moment.
After running into “session could not be started because it was already started with session_start() or session.auto_start” on a project, I realized that removing the cronjob is not the only thing that needs to happen to let PHP manage it’s own sessions.
I’m assuming that this more paranoid than usual security measure was a way to help inexperienced admins and developers to help prevent session hijacking should the web server be breached. However, if root is gained, it doesn’t matter anyway. I’m not going to say that I am an expert in security for servers, but I can tell you that Debian, and therefore Ubuntu, are the only ones doing this type of paranoid security practice. Coming from the FreeBSD world, you are responsible for the security of your machine, not the developers or port maintainers.
In a project for work I came across a bug in our CSS that would leave our nav bar in IE8 (possibly IE9) with a gradient that went from blue to dark blue. As part of this project we went with Twitter Bootstrap and are using Assetic and LessPHP to manage and compile the less files. I didn’t understand why we had this issue as we had the gradient, just the wrong colors. So I started digging into the less files, and then finally the compiled CSS.
While working on a project I kept receiving a blank screen after enabling a function that used Zend_Db_Table_ResultRow’s findManyToManyRowset(). The log file showed the following error, with a long stack trace of the FirePhp plugin looping on encoding the object.
PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 83 bytes) in /mnt/hgfs/myproject/library/Zend/Wildfire/Plugin/FirePhp.php on line 778
In order to figure out the problem I chose to disable FirePhp, this seemed like the logical option considering how FirePhp was stuck.
The error was displayed by ZF, and after adding a primary key to the relationship DbTable ZF went on its merry way. In the end FirePhp was enabled and happily continued about it’s business.