I have a reading list of blogs and other websites in Feedly that I read throughout the day, every day.It includes everything from traditional news through to cartoons.
Often I find something that I want to share on this blog. I
quite often share links here to other articles, but I always try do it in the
context of providing my own commentary and thoughts on the content. What Iām
getting at is that sharing links on here is not a quick, one-click process,
because I donāt want this blog to be merely a long list of links to other
peopleās content. Iām much too egotistical for that.
Anyway, the result of all this is that over time I build up
a handful of flagged articles that Iāve been intending to share but never got
around to doing so.
This is the first of what may become a semi-regular feature,
where I spew those forth with (in the interests of time) only a sentence or two of comment instead of the full-blown article I was originally planning. Enjoy!
Three Communication
Strategies for Building Strong Relationships from Far Away Working in a ROWE is great, but is not without its
challenges. Communication is by no means impossible, but can certainly suffer
when the face-to-face aspect it lost: particularly with a team thatās become
subconsciously reliant on bumping into people in the hallways. This article
lays out some strategies for addressing that. Ā
Why
Resource Management is Better from a Dedicated PM Another post from the excellent Brad
Egeland, this one talks about why a dedicated project manager is better
than using somebody with another role (like a lead designer) to occasionally
manage projects as the need arises. Ā
Fluency
with Excel and Word are Key to Getting a Higher-Paying Job I wanted to link to this article because it surprised me. Higher-paying
compared to what? Isnāt fluency with office applications a prerequisite for getting any
job? Maybe āfluencyā is the key word here, and a basic understanding is a prerequisite
and those with more advanced skills will find more opportunities to progress up
the corporate ladder, but the article doesnāt really say that. This is the
knowledge economy here, people! We donāt make things anymore, unless of course
you count spreadsheets. Get on board! Ā
How to Put an End
to Workload Paralysis I absolutely suffer with this. As the author notes about herself, āthere seems
to be a tipping point for me when I go from being really busy to so-busy-Iām-paralyzed-and-canāt-do-anything.ā
The four steps to fighting this paralysis are not rocket science, but of course
nor should they be, and itās well worth a read if, like me, youāre an
occasional sufferer. At least you now know youāre not the only one.
Last week I linked to and wrote about an article
that gave some tips on running effective meetings.
In addition to posting it here I also posted it, in advance,
to my workplaceās internal social media platform to share it with my team and
get their thoughts on meeting best practices.
My boss Matt
commented that one of his tips was to highlight any meeting pre-work that may
exist: information that participants need to bring with them to the meeting, or
documents they should review in advance, for example. Matt suggested that it
may sometimes even be worthwhile to go so far as to include these expectations
in big bold text within the invite so they jump out.
This was an interesting topic to me, because I am certainly
an occasional offender in this regard.
Basically, if you send me an email that includes a call to
action then I will notice it and deal with it appropriately. I may not take
the requested action immediately, of course, but Iāll flag the email for
follow-up when I know Iāll have time to get it done, or maybe even schedule
some time in my calendar if the situation warrants it.
A calendar invite is different, though. No matter how hard
you try and how good your writing skills are, the instruction in the body of
the invite is not the primary call to action when I receive it: instead, thatās
something thatās defined for me by Outlook (or your client of choice) which is
demanding that I choose to accept, tentatively accept or decline the invite
itself. Once Iāve done one of those things the invite is forever gone from my
inbox, and the meeting (along with whatever instruction you provided) is now on
my calendar.
Iāll get to your email on whatever schedule my workload
allows for, but my calendar by its very nature is a schedule, and it tells me when I should get to something. The
next time Iāll look at your meeting invite is probably going to be two minutes
before it starts, when Iām looking for conference line details or checking
which room itās in. By then of course itās too late.
Recently Iāve started employing a new trick to deal with
this kind of thing for meetings that I host. First I send an email to the group
explaining what needs to be done (pre-work), suggesting that we collectively
discuss to share our thoughts, and mentioning that I will set up some time to
achieve this. Then I immediately follow-up with a meeting invite, into which I
embed that first email.
I havenāt heard any comments, good or bad, but it seems to
be working.
What does everyone think, though? Am I spamming people and
over-contributing to their already burgeoning inboxes? Am I solving a problem
that people donāt actually have and unfairly assuming that everyone shares the
same lack of organizational skills that I possess?
I use a service at home to unlock region-locked web content, particularly internet video. As Iāve mentionedpreviously, I run a Windows 2008 R2 server on our home network which is our domain controller, and (as a result) our DNS server too.
The service I use for unlocking content requires that you set the DNS server on the network to the values it specifies. Thatās not viable for me because of course the client machines need to use the internal DNS server in order to be able to find the domain controller, but no problem – the windows server VM can act as the DNS server just fine, handle requests relating to the internal network domain itself, and forward everything else off using the forwarders I specify (which come right from my content unlocking service).
This worked great until a few weeks ago, and then it suddenly stopped working.
I donāt know why and Iām not quite technical enough to fully grasp the details, but the problem was EDNS (whatever that is). The blog post Iāve linked above talks about it more depth, but the bottom line for me is that once I turned EDNS off everything worked fine.
Itās been a while since Iāve shared one of my somewhat-humorous Friday updates, so I present for your viewing pleasureĀ āSh*t Project Managerās Sayā
Weāve certainly watched this a few times on my team at work and subtle references to it slip in all over the place. I donāt think Iāve previously shared it here though, so enjoy!
I read the article (linked above) by Brad Egeland a couple of weeks ago, and I wanted to share it here because I agree with him, and I think these are great tips. They also apply to any meeting, not just project meetings.
The article also serves as a great reminder that project management is all about people. You could be the best in the world overseeing requirement elicitation for a project, turning that into a work breakdown structure, then a network diagram, then a project plan with schedule and cost baselines… if you canāt run an effective meeting then youāre unlikely to be able to successfully execute upon your plan. These are skills that cannot be forgotten about and the importance of which should not be minimized.
Here are five key practices you can follow to ensure your meetings are effective, well attended and convey the proper information while staying on track and on time.
Sometimes the operative word in your job title isĀ āproject,ā but more frequently itāsĀ āmanager.ā
My favourite piece of advice from Brad is the first one: Send out an advance agenda. Adding an agenda to every meeting I host has changed my life. The mere act of forcing myself to think carefully about the agenda ahead of time has inherent value for me, and youād be surprised (or maybe you wouldnāt) how often giving this the right thought causes me to reevaluate in some way, maybe by adding or removing invitees, maybe by lengthening or shortening my planned meeting length, or maybe by changing the communication medium altogether and replacing the meeting with a phone call or an email. It also helps participants identify whether they really should be involved or not: maybe Iāve misunderstood someoneās role and they wonāt have anything to contribute, or maybe thereās someone on their team that the meeting should be forwarded to for the benefit of obtaining whatever additional insight that person holds. It really helps make meetings effective and minimize the need for follow-ups.
To my mind, in fact, itās so important that I would go a step further ā or more accurately, take one additional step back: define a one-sentence meeting āpurposeā up front as well, and share that in the invite too. It doesnāt have to be complicated by any means, but itās a powerful tool to use if (when) a particular meeting starts to get off track, and itās also something concrete to come back to at the end. Have we collectively achieved the defined purpose? If not, are we each clear on our individual next steps in order to move expeditiously toward that goal?
You can think of a meeting like a small project in its own right, if it helps: the meeting purpose statement is your project objective, and the agenda is the scope statement that flows from that. You could even include anĀ āout of scopeā section if you feel in advance thereās a risk of people getting off topic for one reason or another.
My home network is domain-based, and Iām running a Windows Server 2008 VM as the domain controller. Iāve written
in the past about how to use PHP to do authentication using domain
credentials, and that works great for some scenarios. As a case in point, I use Pydio to host a web-based file manager that
allows me access to my files when Iām out and about. Pydio runs on a linux
server VM on my home
server, and it actually includes a built-in mechanism to authenticate
against an LDAP server (the Windows domain controller) so I didnāt have to
modify it with my PHP code. The principle is the same, though.
This is all good stuff for anything hosted on my home
server, but what if that isnāt what I want? What if I want to host something on
my external, public webserver, and still use my active directory credentials to sign in to
it? And, while weāre at it, what if I want to be even more restrictive and
limit access to a particular organizational unit within active directory?
As luck would have it, these are all problems that I solved
this week. Read on!
Creating a Reverse SSH Tunnel
The first thing we need is to establish a secure connection
between the external webserver (the VPS) and the internal webserver (the local
linux VM). Weāre going to use a reverse SSH tunnel to do this,
and, specifically, weāre going to use a tool called autossh that will keep an eye on
the tunnel and restart it if something goes wrong.
Iāll skip most of the technical detail here, but essentially
a reverse tunnel is going to forward a particular port on the external server
to a particular port on the internal server. Itās called a reverse tunnel
because itās the internal server that triggers the connection. Thatās important:
the internal server can reach the external one just fine, but not the other way
around (thanks to things like me having a dynamic IP address for my home
internet connection, my home routerās firewall, DHCP, etc).
I installed autossh on my Ubuntu server VM:
sudo apt-get install autossh
And then wrote a one-line script that I placed in /etc/network/if-up.d:
Teasing this apart just a little, it uses the local account ālocaladminā
to run the command enclosed in the quotation marks. That command forwards port
8080 on āremote-server.comā to port 80 on the local machine.
For this to work itās essential that the user ālocaladminā
is able to log on to āremove-server.comā without
needing to enter a password.
The Local Server
The local webserver is where most of the heavy-lifting is
going to take place. The first thing I did was create a new virtual host in the
webserver configuration on that machine. Iām using lighttpd, so my configuration looks like
this:
Essentially it creates a new host with the hostname āauth.gatewayā
thatās only accessible to the local machine (127.0.0.1). Any request that comes
in regardless of the URI is rewritten to a file called auth.php in the document
root.
The hostname here isnāt real (i.e. thereās no public DNS
entry for it), and thatās probably a good thing for the sake of locking down
security as tightly as possible. Also on that line of thinking is the fact that
access is limited to the local machine. The webserver doesnāt know that requests
coming through our SSH tunnel are coming from another machine thanks to the
virtues of port forwarding ā it thinks theyāre coming from other processes
running locally (i.e. coming from 127.0.0.1).
Next is auth.php itself, the engine that runs all this
stuff:
As you can see, this is quite a bit more sophisticated than
the previous example in my SSO post, but letās tease this one apart at a high
level too.
When the script is loaded, it first checks to see if the thereās
a username, password and āAUTH_KEYā contained within the HTTP headers of the
request. If so, it verifies that the āAUTH_KEYā is what it was expecting, and it
tries to use the username and password to establish an LDAP connection to the
Windows server VM. If thatās successful, it retrieves some information about
the user and checks if theyāre a member of the required organizational unit.
If all that works it sends back an empty page, but,
crucially a HTTP 200 status (meaning everything is OK). If any of those checks fail
then it sends back a HTTP 401 status (unauthorized) header instead.
In addition to this, the script creates a PHP session with a
custom name. The name is custom to avoid collisions with any session that
the external server may be creating, but essentially the session lasts 10
minutes, and if subsequent requests come in for a user thatās already been
authorized then it skips all the checks and just sends back the HTTP 200
header. It does that because without it, every HTTP request made to the remote
server (not just every page served, but every image on every page, every CSS
file, JavaScript file, etc, etc) would involve a query to the domain controller
to validate the credentials, and thatās a potential bottleneck with performance
implications.
The Remote Server
My remote server is running nginx as its webserver (Iām new to it,
but I think I like it better than lighttpd. Thatās kind of beside the point
though). The configuration looks like this:
When we tease this one apart, there are two key details. One
is that āauth_requestā declaration in the fourth line. As per nginxās
documentation, auth request āimplements client authorization based on the
result of a subrequest.ā In other words, instead of nginx doing the
authentication itself it forwards the request on. The configuration above
defers the authentication of http://example.com to http://example.com/__auth.
The second crucial chunk of the configuration file is
everything within the ālocation = /__authā declaration. The first thing this does
is turn off the āauth_requestā functionality (otherwise, weāre stuck in an
endless loop), and it then creates a proxy to redirect any requests to http://example.com/__auth to http://localhost:8080. Port 8080, if you recall,
is in turn forwarded through our SSH tunnel to port 80 on the local server.
Additionally, it sets the hostname involved in the request
to āauth.gateway,ā forwards a couple of other pieces of information as headers,
and, for some added security, sends an āX-Auth-Keyā header that our PHP script
checks for.
Back outside of this block the āauth_request_setā
declaration takes the session cookie from our PHP script and saves it to a
variable, then the following line (āadd_headerā) sends that cookie back to the
clientās browser as part of the response they receive.
Done!
Real World Problems with All This
I mentioned earlier that we set a session cookie as part of
the whole interaction to avoid the need to query the LDAP server for every HTTP
request the remote server receives, and I said this was to avoid a performance
bottleneck. Thatās true, but we still have a performance bottleneck here: for
every HTTP request the remote server receives itās still querying the local
server through our SSH tunnel, even if all the local server is doing is
responding that the credentials are good based on the existence of the session
cookie.
This communication has to take place over my home internet
connection, which is absolutely not what my ISP intended it to be used for. I don’t think it’s against their terms and conditions or anything like that, itās just that it isnāt
really fast enough.
If the site deployed on the remote server was one of my own
making then Iād modify this approach to create an authentication API of sorts
on the local server, and Iād do the session setting and credential caching
entirely on the remote server, drastically reducing the number of queries to
the local server (all the way down to a single query, in fact, when the session
is first created and the user logs on).
The other problem is one of securing the whole interaction.
Weāre using ābasicā HTTP authentication methods here, which means that the
username and password are passed around in the clear (theyāre not encrypted or hashed as
part of the process). Thatās necessary: the auth.php script has to receive the
password in cleartext because it has to pass it to the Windows server to check
its validity. Itās also not an issue with the communication between the remote
and local webservers, because that happens through an SSH tunnel thatās using
public/private keypairs to provide encryption. It is a problem for the
communication between the user and the remote webserver though, and it leaves
our user vulnerable in several ways (especially if theyāre using a public WiFI
hotspot). Essentially what Iām getting it is that you must use SSL between the user and the remote server.
Conclusion
This is not the most optimal way of doing things,
particularly in regards to the bottleneck it creates by deferring authentication
of every HTTP request to my local server which is connected to the internet
using a typical consumer-grade ADSL connection, but as a quick and dirty way of
securing resources on my public webserver without needing to modify the
resource itself in any way, it works great!
I want my public web server, which runs nginx, to authenticate against my active directory server using LDAP. Iāve written in the past about how to use PHP to authenticate against active directory in this way, but there are a couple of problems: my active directory server isnāt accessible to the internet, and I want to use standard HTTP authentication instead of username and password boxes included on a webpage.
The answer, I think, is to put an authentication PHP script on my home server, make that available to the public web server through an SSH tunnel, and then use nginxās Auth Request module to authenticate against it using the public server as a proxy.
This is – I hope – less complicated than it sounds. Weāll see, and Iāll post more if and when Iām successful, but the problem Iāve initially run into is that nginx in Ubuntuās repositories doesnāt include the Auth Request module. I have remove nginx and re-install it from source, compiling it with the additional module included.
Itās a bit of a daunting process, but the page Iāve linked seems like it will take me through it step by step.
Iāve written many times on this blog about ROWE (the results only work
environment). Itās the structure under which I work, and Iām a big fan. One of
the key tenets of ROWE is that itās available to everyone: itās not something
reserved for those at a certain paygrade, itās not restricted to leaders, itās
not something you have to apply to be a part of, or provide some kind of
justification of your particular circumstances to gain entry. There should be
no barrier to entry.
When I first
wrote about ROWE on this blog, I lamented that at my organization there is
a barrier to entry, to a certain extent. Not by design, but simply because our
communication mechanisms are restricted by our firewall and access to them from
outside the corporate network is barred. The barrier to entry, as I see it, is
having a company-issued cellphone. If you have one you can be available from
wherever you might happen to find yourself, and if you donāt youāre tied to
your computer.
I didnāt have a company-issued cellphone when I wrote that,
but I do now. There it is above. Itās the one with the darker wood effect
amongst my bamboo effect personal devices.
I love it, and I hate it. I donāt want it, and I wouldnāt
give it back. Read on to learn why!
Why I Love It, and How it Supports ROWE
Quite simply, when I thought not having this device
constituted a partial barrier to ROWE entry, I was right. Last week Flo and I
went to Winnipeg and I worked from there for the week. I spent most mornings
sitting in Floās sisterās kitchen working at my laptop, then weād typically go
for lunch together and Iād spend the afternoons with my extended family. I was
available throughout to respond to emails and IMs. If somebody called my office
phone number then their call was seamlessly forwarded to the phone in my
pocket. Most of the work people I interacted with would have had no idea I wasnāt
at my desk, let alone that I wasnāt even in the same time zone. That wouldnāt
have been possible if I didnāt have this phone.
Why I Hate It, and How it Contradicts ROWE
The point ROWE is that Iām an adult, and I work how, when
and where I choose to. I could be
working at any time and from any place. Having the phone feels a little bit
like I am working at all times, from all
places. Essentially having the phone means the thing I find most challenging about
working in a ROWE ā knowing when to switch off ā is magnified exponentially.
Obviously the phone has an āoffā button and, being an adult and all, I am free
to use it as I choose, but I simply donāt find it as easy as that. Take last
week as an example: when I was out spending my afternoons with family every now
and then Iād receive a work-related message of some description. I probably
dealt with 80% of them right away, because 80% of my job is more about getting
the right people in contact with one another than it is about actually doing
something myself. The remaining 20% I flagged to deal with the following morning.
The inward flow of these messages is not overwhelming, but it is constant. If I
disconnect entirely, even for an afternoon, the sheer volume of stuff that
builds up is overwhelming. I donāt
like to feel overwhelmed, so I keep my phone on because itās easier to take a
couple of minutes out of what Iām doing a few dozen times than it is to try to
deal with a few dozen things at once when I eventually choose to reconnect.
There are certainly times where I hate remaining available
and connected and doing so gets in the way of other things Iām doing at that
moment, but despite that the logic above kicks in and even when I need a break
I end up being reluctant to take one. And, as I mentioned, the inward flow of
messages really is constant. With most of the people I work with also being in
a ROWE it starts at about 6am and continues until about 1am, each one bringing
with it a little ādingā noise. I feel like Pavlovās dog sometimes.
Why I Donāt Want It
Despite the occasional strength of my negative feeling
toward my phone, none of that has anything to do with why I donāt want it. The
benefits outweigh the drawbacks, and the issues I have with it are a function
of my choices, not of the technology. I can get better with it, and over time I
will.
The reason I donāt want it is that I have a perfectly good
phone already. You may have noticed it in the photo up top: itās the bamboo
effect one in the middle. Why do I need to carry two phones with me? Thereās no
technical barrier to my company turning on the ability to support a ābring your
own deviceā policy, and in fact the technology required is already in place. Itās
disabled, because the policy is that the IT department wonāt allow you to get
email on your phone unless they have the ability to remotely wipe the whole
thing. Not just securely erase company data, but securely erase everything. I
assume this is a case of policy failing to keep up with emerging business trends.
Iād think they must realise that weāre going to have to BYOD policy someday, so
I get hung up trying to understand why they wonāt just get it done right away.
Iāll continue to advocate for a BYOD policy in my workplace, exceptā¦
Why I Wouldnāt Give it Back
My inability to switch off was a minor problem when I
carried a laptop. When that laptop was supplemented with a phone it became a
bigger problem. If that work-only device were replaced with an app on my
personal device through which I access work stuff? It could be disastrous. I
never switch my work phone off, but I do leave it at home when we go out
somewhere in the evening or on weekends. I take my personal phone with me
everywhere though. I assume that BYOD technology includes functionality that
would let me turn āworkā off while keeping āpersonalā switched on, but am I
disciplined enough to use that function? Probably not.
We’re constantly bombarded with stories of people who are doing incredible things and it often makes us think we need a big idea to get started. However, it’s often the little ideas that lead to big things.