PARSEC Technical Information

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
== Introduction ==

The PARSEC Group does a lot of consulting work for customers who'd simply like us to dig in and get our hands dirty instead of trying to support the customer doing the work directly. This is convenient for them and often easier for us, too. However, there are some pitfalls and common mistakes when starting a consulting engagement that are easy to avoid. This document covers the right way to setup a technical consulting engagement. 

== Clear Goals and Communication ==

Good communication is the key to successful consulting. You might want to simply pay someone to do the work, but often there will be a lot of questions that need answering before the consultant will feel comfortable in your environment making changes. 

  - Make sure you have a **clear statement** that encapsulates either the problems you want solved, or the ultimate system-state you want to achieve. A clear problem statement is something like "I have no idea as to the state of my server monitoring or backups." Whereas, the same thing can also be a goal: "I'd like to have full backups and extensive monitoring on all my production systems." Simply put: know the scope and goals of the consulting project before you start!
  - Does the consultant know the **right people** to do the work? For example, if you want someone to build servers with active-active LACP bonding, they would need to work with a local network administrator to setup the switch-side configuration. Make sure the consultant has the phone number and/or email of the right people needed to complete the work.

A simple email with a statement about what you want done and who you'll want us to work with goes a long way. In more complicated situations, a meeting can also help in this regard. 

== Network Access ==

One of the biggest problems we run into with the completion of consulting work is remote access. There are several situations we find ourselves in, most of them are sub-optimal. First, keep in mind that just because a company offshores their VPN administration doesn't mean it'll be easy for the users. We often find we are calling overseas to some "boiler room operation" running a client VPN and the process can easily take hours of back-and-forth communication and security requests. Keep in mind that, if you have such a complicated remote access system that you'll end up paying consulting time/fees for **100% of the VPN setup time**. We cannot absorb the costs & time involved with poorly run VPNs and that gets reflected by your bill. 

If you want to avoid extra charges for remote access, then do yourself a favor and make friends with whoever runs your firewall access. PARSEC uses static Internet IP ranges and can easily provide them to you. This type of direct layer-3 access is always the most direct and accessible method for remote access. Our general order of preference (from best to worst) is:

  - Direct layer-3 IP access. Allow us into your network via a firewall rule. We use Secure Shell for access and it's 100% encrypted. There is no "hit" to your site security with this method. Feel free to limit the access to port 22 (Secure Shell) only, if you are worried about non-encrypted access. This is **by far** the best method for remote access. 
  - Jump server access. Ie.. you put an Internet-accessible system out there and we login to it first, then it has back-end access to the systems you need us to work on.
  - Straightforward "good" VPN access. This option usually means you have your own VPN which is administered and well-understood internally. Examples of this are usually OpenVPN, Wireguard, or Windows PPTP/L2TP connections.
  - Complicated VPN access. We will tolerate your bad VPN (but we'll charge you for the hassle-factor of dealing with it). We consider Cisco ASA/PIX VPN, Juniper, and other proprietary VPNs in this category. It's worse and more complicated if it's externally administered (ie.. call India for access). If it expires and breaks every 30 days we'll continue to bill for any time we have to spend waiting for your VPN/VDI admins to fix our access.
  - Screen Sharing Access. This is by far the worst and most complicated type of remote access. Some customers prefer it because their own VPN access is so "secure" their own employees have a hard time using it much less getting anyone else access. Screen sharing is problematic because it dominates someone's workstation while we are using it (and they often still try to use it, accidentally fighting us for control of the windows). It also requires coordination to setup ever time it's needed. It's not a viable option for more than a simple 1-2 hour incident. Frankly, it's usually a way to paper over major institutional problems with the customer.   

== System Access ==

We will obviously need some way to login to your systems. We can use one account (like "root") for all your systems if that's what you want. We can also use a local login if you want to create that. In any case, we will need **some kind of login info** for your systems or we won't be able to get in. We will also need a list of the systems (and IP addresses if they aren't in your DNS).

So, don't forget to include the following:

  - List of the systems (with IPs if they aren't in your DNS)
  - Account credentials with enough access to login and do what we need.
  - Lights Out access to systems that we need to reboot or build up from bare metal. This means the credentials to your DRAC, ILO, LOM, ILOM, HMC, or whatever your system uses for out-of-band bare metal access.