Author: Ipstenu (Mika Epstein)

Just Push Publish

“Real artists ship.” — Steve Jobs, 1983

I don’t write good all the time. I’m a little lazy and spell poorly, I don’t proofread enough, and if I had a genie to grant me a wish, one would be for an editor who I wasn’t related or married to. When I post a new article, I often see typos and while I do go back and fix them, I still push publish (or schedule), knowing things aren’t perfect.

This is a major departure from the “traditional” way of writing, when you write, have it reviewed, edit, re-write, re-edit, and so on. To many people, this is seen as ‘lazy’ writing, where we toss out things that are ‘good enough’ and call it a day, but the reality is that publishing promptly, be it writing or code, is what keeps up with the fast changing pace of news, information, and needs. But when it comes to writing, it falls a little bit under the aegis of “If you build it, they will come.” Or rather, if you don’t build it, they won’t come at all.

Publish or Perish

Well known to academia is the concept that if you don’t constantly publish works to sustain your career, you won’t have a career. The added pressure is that you have to publish fast so your information isn’t out of date before it hits the ground. The idea is that if you’re not publishing something then you’re not producing something, and you’re thereby sitting on your laurels. In software and blogging, this is actually important too! If you’re not producing code, or writing about it, you’re not demonstrating what you’ve learned. If you release code or write on your blog once a year, people will forget about you.

Release and Iterate

Also known as “Release early, release often,” this model of development makes important the concept of early and frequent releases. This necessitates people test, though, and developers respond quickly to issues reported by users. WordPress works by this model. Reid Hoffman, the founder of LinkedIn, said “If you are not embarrassed by the first version of your product, you’ve launched too late.” And if you look at many of the recent technological innovations (including the iPhone), version one was okay, but not great, and had a lot of bugs and annoyances.

Fear, Uncertainty, Doubt

The biggest hold up to most of us pushing that publish button is FUD. What if we’re wrong? What if we’re saying things no one cares about? What if… We don’t want to be horribly embarrassed by that typo where we get their/they’re/there wrong, or worse, where we get all that technical information wrong. And it’s that place of fear, that home of uncertainty, that realm of doubt, that we stop. We don’t share what we know, we don’t explain what we think, and we turtle up.

Democratizing Publishing

The mission of the WordPress open source project is to democratize publishing through Open Source, GPL, software. By letting any of us write what we want, we’re able to publish at will. That anyone can upload a book to Kindle or Apple and sell their works has changed the world. In many ways, it’s lowered the bar so anyone can sell anything which causes a dearth of quality. And yet, the stamp of quality products has never rested solely in the hands of ‘official’ publishers. Some of the best music we heard was from underground tapes made in basements. Some of the best stories we read were mimeographed in purple ink and handed out on the QT at fan conventions. All we’ve done here is take the barriers away and given you the freedom to say what’s on your mind.

Write the Change You Want to See

It takes bravery to post your thoughts, technical or personal, out there. You should only put out work you can stand behind, you should put the best work you can do out there, but you should be willing to post. You should be willing to release that code. You won’t grow, you can’t grow, if you don’t step up and put yourself out there.

Don’t worry. We know you’ll fix it.

30 July, 2014
Home Affects Your Website
There’s a vulnerability with an old version of MailPoet, which according to Sucuri, is the reason for the breaking of ‘thousands’ of WordPress sites. I do not doubt their claim, nor the validity of the statement, but I did wince mightily at their wording.

At the time of the post, the root cause of the malware injections was a bit of a mystery. After a frantic 72 hours, we are confirming that the attack vector for these compromises is the MailPoet vulnerability. To be clear, the MailPoet vulnerability is the entry point, it doesn’t mean your website has to have it enabled or that you have it on the website; if it resides on the server, in a neighboring website, it can still affect your website.

All the hacked sites were either using MailPoet or had it installed on another sites within the same shared account (cross-contamination still matters).

I bolded the important part here.

I disagree with the broad, sweeping, implication that statement makes. While they do mitigate that with the next paragraph (and yes, you should read the links), it gives a bad impression as to what the issue really is there. If the vulnerable code resides on your server, under your user account, in a web-accessible directory, then yes, it can affect your website. However for any decent webhost, your site being vulnerable will not result in my domain being hacked.

Good hosts don’t permit users to access each other’s files. I know it’s semantics, but the implication is that a stranger’s website on your server will make you vulnerable. And that’s just not a given. I know that explaining the nature of relationships between user accounts and access is fraught with complexity, but this is a place where I look at security sites and bang my head on the table because they’re not educating people.

The way security works for most people is entirely an FUD scenario. They fear what they don’t understand, which generates more uncertainty and doubt. I spent time recently trying to break down that wall and talk about the behaviors in us that make things risky, and I’ll be speaking at WordCamp LA about it in September of this year. I understand totally why Sucuri, and many other people, phrase it this way, but since I firmly believe that education is the only true way to mitigate hacked sites, I want to explain the relationship of files to people.

If you’ve ever FTPd or SSHd into your website, you know you have a user ID. That ID owns the files on your server, but it’s not the only account on a server. Your ID is yours and yours alone. You can give someone else the password, but please don’t unless you trust them with your car. Once you’re logged in with your account, everything you see is connected. This means if you can see it, then anyone else who gets into your account can see it.

How does WordPress play into this? Well if you can see it logged in, then so can WordPress, to an extent. If a plugin or a theme has a specific kind of vulnerability, then it can be used to extract information like everything under that user account. A pretty common vulnerability I see is where the plugin allows you to read any file on the system, including the wp-config.php file, which gives people your database username and password (and it’s why I tell people to change all their passwords).

A very common thing for people to do, and I do this myself, is to run multiple domains under one user account. Many times they’re called ‘add on’ domains. In this case, you can actually visit https://ipstenu.org/helf.us/ and see the same site as you would at https://helf.us. This is problem fairly easily fixed with .htaccess (though if, like me, you also have mapped domains, it gets much messier):
```
RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www.)?example.com$ [NC]
RewriteCond %{REQUEST_URI} ^/addon1/(.*)$ [OR]
RewriteCond %{REQUEST_URI} ^/addonN/(.*)$
RewriteRule ^(.*)$ - [L,R=404]
```
All that said, if someone knows that helf.us and ipstenu.org are on the same server, and the software I use on one is vulnerable, it can be shockingly trivial to infect the other.

What is not trivial would be using an exploit on ipstenu.org to hack ipstenu.com. Yes, it redirects you to ipstenu.org, but it is a real website. The reason I would be shocked to find it infected, if ipstenu.org was, is that they’re under separate user accounts. If you logged in with the ipstenuorg ID, you would not, could not, see ipstenucom.
```
ipstenuorg@ipstenu.org [/home]# ls -lah
/bin/ls: cannot open directory .: Permission denied
```
And even if they knew there was a folder called ipstenucom, the couldn’t do anything about it except get in:
```
ipstenuorg@ipstenu.org [/home]# cd ipstenu.com
ipstenuorg@ipstenu.org [/home/ipstenu.com]# ls -lah
/bin/ls: cannot open directory .: Permission denied
ipstenuorg@ipstenu.org [/home/ipstenu.com]# cd public_html
-bash: cd: public_html: Permission denied
```
The separation of the users is going to protect me.

So to reiterate, if a site (or the account that owns a site) has access to other sites, and is hacked, yes, those other sites are at high risk. If the site has no access to anything but itself, they will not be hacked. And as I said before, most hosts go to tremendous lengths to ensure you cannot read someone else’s files or folders. The whole reason I can get into the ipstenucom is that the permissions on that folder allow it. Would it be safer to prevent it? Sure! And actually that’s not what you normally see when you’re on my servers.
```
ipstenuorg@ipstenu.org [~]# cd ../
ipstenuorg@ipstenu.org [/home]# ls -lah
total 12K
drwx--x--x 37 ipstenuorg ipstenuorg 4.0K Jul 23 02:04 ipstenu.org/
ipstenuorg@ipstenu.org [/home]# cd ipstenu.com
-jailshell: cd: ipstenu.com: No such file or directory
```
That’s right, I use jailed shell to prevent shenanigans, and even when I don’t, things are remarkably safe because I don’t permit users to snoop on other users. That said, as I was reminded we must never underestimate the ability of a fool, playing at sys admin work, to take their own pants down. It’s possible for a user to set up their own domain to be searchable by other accounts on the server, and to make it writable to those other users, which can cause a lot of problems.

Here’s your takeaway. Everything that is installed on your domain, active or not, is a potential vulnerability. Upgrade everything as soon as you can, delete anything you’re not using, don’t give more people the keys to the castle than you have to, and try really, really hard to think about what you’re doing.
28 July, 2014

Mailbag: Pinging Pingbacks

I run a fan site, and so does a friend of mine. Liv and I were chatting about wishlists in WordPress for fansites, and she mentioned this:

I also like seeing who has linked to my site from other WP blogs because that helps me create fandom connections with other bloggers. I wish there was a quick button I could hit that would allow me to email those bloggers with a quick note of thanks for the connection

When you’re running a fan website, communicating and connecting with those other sites is a killer feature. We network and that’s how we make our communities bloom, after all, since most of us can’t afford a budget for ‘real’ advertising, and it’s probably not entirely legal for us to do that anyway. So outside of spending days tracking everyone down, what about using the power of ping-backs for ourselves?

I’m sure Liv has an unshakable confidence in my ability to code her things (and I love the requests she makes, they stretch my brain) but this one kicked my patootie a lot. Getting a list of pingbacks isn’t all that hard. There’s a plugin called Commenter Emails by Scott, which nicely lists all the email addresses used to make comments. Using that logic, it’s pretty easy to list all the pingbacks. I mean, hey, we can already do that!

If you go to /wp-admin/edit-comments.php?s&comment_status=all&comment_type=pings you’ll see all your pings:

Just looking at that, however, made me notice a horrible problem. There are no emails listed in pingbacks. This makes perfect sense. The emails aren’t (generally) listed on a page that links to your site. That means without doing some serious site-scraping, there’s no way to get that email.

Putting that aside, the other option is to, perhaps, list the ‘parent’ domain that pinged you. So I went back to Scott’s plugin and forked it into this:

&lt;?php

/*
Plugin Name: Pingers List
License: GPLv2 or later
License URI: http://www.gnu.org/licenses/gpl-2.0.html
Description: List all pingbacks with links to their main domain.

	Quasi fork of http://wordpress.org/plugins/commenter-pings/

	Copyright (c) 2007-2014 by Scott Reilly (aka coffee2code)
	Copyright (c) 2014 by Mika Epstein (aka ipstenu)
*/

defined( 'ABSPATH' ) or die();

if ( is_admin() &amp;&amp; ! class_exists( 'PingersList' ) ) :

class PingersList {

	private static $plugin_basename = '';
	private static $plugin_page     = '';

	/**
	 * Returns version of the plugin.
	 *
	 * @since 2.1
	 */
	public static function version() {
		return '2.2.1';
	}

	/**
	 * Constructor
	 */
	public static function init() {
		self::$plugin_basename = plugin_basename( __FILE__ );

		// Register hooks
		add_action( 'admin_menu', array( __CLASS__, 'admin_menu' ) );
		add_action( 'admin_menu', array( __CLASS__, 'do_init' ), 11 );
	}

	/**
	 * Initialize hooks and data
	 */
	public static function do_init() {
		// Currently empty
	}

	/**
	 * Query database to obtain the list of commenter email addresses.
	 * Only checks comments that are approved, have a author email, and are
	 * of the comment_type 'comment' (or '').
	 *
	 * Only one entry is returned per email address.  If a given email address
	 * has multiple instances in the database, each with different names, then
	 * the most recent comment will be used to obtain any additional field data
	 * such as comment_author, etc.
	 *
	 * @param array $fields  The fields to obtain from each comment
	 * @param string $output (optional) Any of ARRAY_A | ARRAY_N | OBJECT | OBJECT_K constants. See WP docs for wpdb::get_results() for more info
	 * @return mixed List of email addresses
	 */
	public static function get_pings( $fields = array(  'comment_post_ID', 'comment_author', 'comment_author_url' ), $output = ARRAY_N ) {
		global $wpdb;

		// comment_author_url must be one of the fields
		if ( ! in_array( 'comment_author_url', $fields ) )
			array_unshift( $fields,  'comment_author_url' );

		$fields = implode( ', ', $fields );
		$sql = &quot;SELECT $fields
				FROM {$wpdb-&gt;comments} t1
				INNER JOIN ( SELECT MAX(comment_ID) AS id FROM {$wpdb-&gt;comments} GROUP BY comment_author_url ) t2 ON t1.comment_ID = t2.id
				WHERE
					comment_approved = '1' AND
					comment_type = 'pingback'
				GROUP BY comment_author_url
				ORDER BY comment_author_url ASC&quot;;
		$pings = $wpdb-&gt;get_results( $sql, $output );
		return $pings;
	}


	/**
	 * Creates the admin menu.
	 *
	 * @return void
	 */
	public static function admin_menu() {
		add_filter( 'plugin_action_links_' . self::$plugin_basename, array( __CLASS__, 'plugin_action_links' ) );
		// Add menu under Comments
		self::$plugin_page = add_comments_page( __( 'Pinger List', 'pinger-list' ), __( 'Pinger List', 'pinger-list' ),
			apply_filters( 'manage_commenter_pings_options', 'manage_options' ), self::$plugin_basename, array( __CLASS__, 'admin_page' ) );
	}

	/**
	 * Adds a 'Settings' link to the plugin action links.
	 *
	 * @param array $action_links The current action links
	 * @return array The action links
	 */
	public static function plugin_action_links( $action_links ) {
		$settings_link = '&lt;a href=&quot;edit-comments.php?page=' . self::$plugin_basename.'&quot; title=&quot;&quot;&gt;' . __( 'Listing', 'pinger-list' ) . '&lt;/a&gt;';
		array_unshift( $action_links, $settings_link );
		return $action_links;
	}

	/**
	 * Outputs the contents of the plugin's admin page.
	 *
	 * @return void
	 */
	public static function admin_page() {
		$pings = self::get_pings();
		$pings_count = count( $pings );

		echo '&lt;div class=&quot;wrap&quot;&gt;';
		echo '&lt;h2&gt;' . __( 'Ping List', 'pinger-list' ) . '&lt;/h2&gt;';
		echo '&lt;p&gt;' . sprintf( __( 'There are %s unique ping locations for this site.', 'pinger-list' ), $pings_count ) . '&lt;/p&gt;';
		echo '&lt;/div&gt;';

			echo '&lt;div class=&quot;wrap&quot;&gt;';
			echo '&lt;h2&gt;' . __( 'All Pings', 'pinger-list' ) . '&lt;/h2&gt;';
			echo '&lt;table padding=2&gt;';
			echo '&lt;tr&gt;&lt;th&gt;' . __( 'Post', 'pinger-list' ) . '&lt;/th&gt;&lt;th&gt;' . __( 'Source', 'pinger-list' ) . '&lt;/th&gt;&lt;th&gt;' . __( 'Direct Link', 'pinger-list' ) . '&lt;/th&gt;&lt;/tr&gt;';

			foreach ( $pings as $item ) {
			
				$pings_url = parse_url(esc_html( $item[2] ));
				$ping_url = $pings_url[scheme].'://'. $pings_url[host];
			
				echo '&lt;tr width=&quot;20%&quot;&gt;&lt;td&gt;&lt;a href=&quot;' . get_permalink( $item[0] ) . '&quot;&gt;'. get_the_title($item[0]) .'&lt;/a&gt;&lt;/td&gt;';
				echo '&lt;td width=&quot;20%&quot;&gt;' . make_clickable($ping_url).'&lt;/td&gt;';
				echo '&lt;td&gt;&lt;a href=&quot;'.esc_html( $item[2] ).'&quot;&gt;'. esc_html( $item[1] ) . '&lt;/a&gt;&lt;/td&gt;&lt;/tr&gt;';
			}

			echo '&lt;/table&gt;';
			echo '&lt;p&gt;' . sprintf( __( '%s pings listed.', 'pinger-list' ), $pings_count ) . '&lt;/p&gt;';
			echo '&lt;/div&gt;';


	}
} // end PingersList

PingersList::init();

endif; // end if ! class_exists()

The plugin’s crazy basic. It simply checks for unique ping sources and lists them. So if the same ‘main’ site links to you 10 times from 10 separate posts, it lists that. Probably a nice tweak would be to order them by domain, list the posts they link to and from where, and have a group by sort of list, but I didn’t get that far into it. Forks welcome, as are full blown plugins!

25 July, 2014

La Vitesse 2: Cruise Control

Now you know all about caching and how it works. But what about speeding up the server itself?

Near the end of the previous post, I mentioned that all the caching in the world didn’t really speed up the server. This is somewhat of a lie, since if, say, you’re using Varnish to cache your site, then your visitors won’t be hitting your WordPress install, speeding it up for you to do work. But it’s not the full picture.

WordPress is big and it’s getting bigger and more complex and more impressive. So is Drupal and … well pretty much everything else. In order to make your site do more, like all that super fancy layout transformations, we have to upgrade and innovate. But then you start getting into extending these apps, like using custom fields and extra meta values to store more information so you can change search results in more impressive ways! Your site scrolls and changes backgrounds! Your site dynamically changes what products are available based on check boxes, without reloading!

What did that have to do with caching? Well … how do you cache things that aren’t static?

My coworker, Mike, likes to talk about things that should be cached and things that should never be cached. Things that have to be dynamic and run without a page refresh, like ajax and javascript, can be cached to an extent, since those plugins and Varnish will just keep the code in-line, which means it’ll still run. But when you start looking at dynamic things like shopping carts, we hit a new world and a new wall. But I’m not even talking about that level of caching. I’m talking about going back a layer into the part where WordPress (or any app) has PHP query the database. If we speed that up, caching safe content, can’t we speed things up? You bet we can!

A few years ago I talked about APC and how I was using it to speed up PHP by having it cache things. Then less than a year later, I switched to Zend and memcached. I did those things because I decided that it would be better to have my server, a workhorse, do the hard work instead of asking WordPress to do it. And this was, in general, a pretty good idea.

Memcached is an add-on for your server, and acts as “an in-memory key-value store for small chunks of arbitrary data (strings, objects) from results of database calls, API calls, or page rendering.” In English? It remembers what you did and can retrieve results faster because of it. Of course, you have to tell your apps to play well with it, but once you do, the backend of your site starts to speed up because, hey, caching! The Illustrated Memcache’d story is kind of an awesome explanation (the images on the archive page are broken, but the links work). And yes, I do use memcached and ZendOptomizer+ on my server, because it really does make things faster, even when two of the ten domains are having a 10k pageviews in a day.

I keep telling everyone my server isn’t overkill….

The point of that, though is the other end of speed is totally separate from your application code. When you install WordPress, you know it runs SQL and PHP, so if you can make those faster, WordPress will be faster. The same applies to speeding up Apache, maybe by putting Nginx in front of it, or maybe by tuning the hard to understand settings in httpd.conf to make sure that it elegantly handles the 300 people who come running to your site at once.

But unlike plugins, this aspect of server speed is the hard stuff. When you look at WP Super Cache, you think it’s complicated until you see W3 Total Cache. Both are amazing and awesome, but they’re giving you a ton of options and asking you to make decisions. The same is true of the servers, but now you have even more options. The world is your oyster, and we haven’t even looked at hardware.

For me, it boils down to how can I make my server do it’s job fast and efficiently. If that means I hire someone to install software to cache better, or I pay for more memory, then that’s what I do. I also trim the fat and get ride of everything I’m not using and don’t need, so my server doesn’t have to do more than it needs to. And one day, one day, I’ll be looking at nginx for everything.

23 July, 2014
La Vitesse

A little bit ago I talked about Varnish, how to install and configure it, and why I’m not using it at the moment. The actual goal of all this stuff is to speed up a website. Site speed is an insanely fickle beast, and measuring it without going insane is nigh impossible.

When we talk about site speed we don’t just mean how fast the site loads. We mean how well it performs on the front and back. Does it load everything it needs to be a page in a non-jumpy way? Does it load and then magically change to another format because you’re on an iPad? Does it hang and then load? We mean all those aspects that go into a site and make it zippy.

Which brings us to caching. The goal of caching is blindingly simple: Don’t put extra load on the server while serving up webpages and make it faster. The how of caching is crazy.

When I talked about Multisite Caching, I brought up the different types and why and where I saw each one being used. But I didn’t really explain why very well. In order to understand it, you need to understand why we need to cache.

If your website was all plain, static, HTML files, it would be really fast. The web was (initially) built for that stuff and it was all basic. “I want this page.” And the server would reply “Okay, here it is and some images.” When we start adding in stuff like dynamic PHP (WordPress), we put more load on the server because for every time someone visits your site, it has to ask WordPress “Do you have this page?” and WordPress has to check, see if it does, generate the output, and then it loads. The more complex the site is, the more big images and javascript fancy stuff, the slower the site gets.

Logical stuff, right? You’re also going to be limited by how fast your server is and how much of it you can use. If you’re on a dedicated server, the limit is your hardware and bandwidth pipe. If you’re on shared, though, the limit is lower, and really varied and complicated. While I mention a ‘bandwidth pipe’ and we techs always joke about the sturdy internet tubes, it’s not a fully accurate analogy, and even with all the bandwidth available in the world, the speed of your server is going to limit you far more.

There’s a phenomena called the “noisy neighbor” which impacts people on shared hosts a lot and is a lot of why people get confused about the bandwidth thing. You see, if you’re on shared servers, you share services. If one of your neighbors uses a lot of memory, there’s less available for you. This makes perfect sense, and hosts combat this by limiting how much you can do. I know a lot of companies say that you have ‘unlimited’ space and bandwidth, and while that’s true, it doesn’t mean you get to use all the power available to the server. Basically on shared servers, when you see ‘unlimited’ you should read it as ‘unlimited until you start making other people’s sites run worse.’

What does this have to do with caching? It’s the reason why we cache! WordPress does not make static HTML pages at all. If you look on your server for a file named ‘about’ you won’t find one. Instead, WordPress uses the .htaccess file to magically run your request for example.com/about/ through the index.php file, which then checks the database and pulls the content for that page. It’s entirely dynamic, and every single page request is run through the database. And yeah, that gets slow over time. The dynamism is fantastic though, and that’s why things like comments magically update the rendered page right away.

Thus, in order to make our super dynamic websites run by WordPress run faster, we turn to methods to generate static file caches. Converting a WordPress page from the PHP queries to a static file is complicated, and in essence every single tool has to generate that dynamic page, copy the output, and save it to a location where it can be pulled from directly. At the same time, it has to alter the server in some way to say “If I have a static file, use that instead.” When you use a plugin, generally it does this via your .htaccess file.

The obvious problem with this is that while the page may be faster for visitors, you’re still putting load on your server by having it generate these html files and serve them. And you, the logged in user, won’t get the cached page, generally, not even with something as cool as Varnish, so we have to still consider the rest of the server.

Speaking of Varnish … the simplest explanation I can give you about it is this: Instead of having WordPress use a plugin to generate the page, Varnish lets WordPress load, takes a snapshot of the resulting page, and saves it somewhere else. That means that in-between your visitor and the WordPress install is the Varnish cached page, which means the load is off your server more! No more loading the html page, Varnish is going to do it and make it a little faster. You’ll still want a plugin to allow WordPress to tell Varnish to delete pages, but it can significantly run faster.

But … what about the server speed itself? Is there a way to cache that and speed it up to? There is! But that’s a longer post, all it’s own.

21 July, 2014
Mailbag: Playing the Middle

This is from Ben in Minnesota and … It’s not about WordPress as much as learning and support, but here is the meat of his issue:

I’m just learning things. I’m really familiar with Drupal and okay with a vps, but I took over a WP install on a dedicated server and I’m way out of my league! I don’t understand half the questions. They treat me like I should know everything already because I’m experienced and tell me to just ask the vendor. But the hardware scares me and I don’t know how to get the information I need to solve things!

Do you have any advice, besides learning faster?

My least favorite role is when I have to play the middle man between two tech groups. Group A has a problem, so they ask me to ask it of Group B, and I have no familiarity with what the subject is. Happens a hell of a lot, and it exposes the lack of depth of knowledge in specific areas.

I hate it. It makes me feel like I’m stupid, and then when I ask for clarification, I get vague, top-level answers and what I need are examples. Much of this has to do with how I learn best, but the other problem is people have a tacit assumption that I know what the hell they’re talking about, when I clearly do not.

Basically? They’re giving me shitty support based on their preconceived notions about how “everyone” thinks. And yes, it pisses me off and I have been at the point of tears of anger me frustration over this before. I’ve been there, man, and recently too. It’s worse probably because I am clever and can pick things up quickly. They assume I know, or will figure it out, so I get half-assed help.

So. What do I do? Well first I quote them. “My DB guy said this [quote]. Do you need any specific information? I’ll ask him, but I’m not familiar with this topic.” Sadly that tends to net me a pretty generic reply like “Just filter it.” It does make me want to scream, you’re not alone there.

Lately I’ve been stopping them before it gets that far, though. When I’m told “Can you ask Group B about this?” I say “Can you explain like I’m 5, real fast, so I can make sure I ask them the right things and make sure that I don’t have to go back and forth really a million times and bug the hell out of you?” If I already understand a little about it, I may say “I thought that ModSecurity could hook into IP Tables and auto-block people who hammered my login files?” to set the tone of what I did know.

Basically the only path out of ignorance is to explain that you are uneducated in this topic, and while you will learn as fast as you can, you need a little more help than that. If they still won’t help you out, take them aside and ask if you’re doing something wrong, because you need their help in a different way than you’re getting. Be firm. Be up front. Be honest.

Good luck, Ben! And just for some fun, here’s a scene from Office Space:

People skills!

18 July, 2014