From an AWS point of view you need to think about servers very differently,

Hi Andrew, Thanks for the below info. The way we have things setup here is that we have iso images which are on a network server, along with kickstart files, (which are generated by packer) - the same packer you refer to. We use the kickstart files to essentially provide an "unattended" install when provisioning machines. However, sometimes, the kickstart process can't find a file, or the dhcp server fails to provide an IP address, or the machine half installs and then bails, forcing the need for machine console access. Depending on how far machine config has got, sometimes I can log in with ssh and troubleshoot, but if ssh isn't available I have to ask a colleague. I will look deepper into packer to see if it maybe provides features to further automate our kickstart process to minimise the need for console access before ssh comes up. Thanks again, Ryan -----Original Message----- From: Blind-sysadmins [mailto:blind-sysadmins-bounces@lists.hodgsonfamily.org] On Behalf Of Andrew Hodgson Sent: 01 April 2017 23:21 To: Blind sysadmins list Subject: Re: [Blind-sysadmins] Access to VMware ESX 5.5 (both gui and VM guest console) Hi, When I am talking about Packer, I am talking about Hashicorp's Packer that builds the image. When working with VMWare, it has two options, either to start from an ISO image or a VMX file. The thing I like about Packer on ESX is it gets you past the boring part of logging onto the console, pressing escape at the right time etc. You then get a predictable image every time that can be used in other places later on. This saves you time as it means that you don't need to provision a new machine and wait for that to complete etc. How many times have you tried to provision a new machine and have some part of it fail as it couldn't access a network file, or something went wrong with deployment etc.? I realise that in most enterprises this type of technology is seen as very new and certainly in the place where I work the team I am in are the only ones using this type of workflow, the rest of the teams are still using older ways to get machines up which are not as usable. I think that in time we will see a lot more of this automation which is good news for us. the servers I spin up in AWS last only for a few weeks, and in AWS terminology for a lot of places that is a long time. I am different in that I am working with a Windows stack, although I do use some Redhat in some places. The AWS console is not too bad, but the real power comes from automating the provisioning of the network and the systems. I typically make heavy use of the AWS PowerShell, and Hashicorp Terraform to build the infrastructure. I am building the infrastructure from the networks, each subnet, connectivity between the subnets, firewalls, network appliances etc., all controlled via Terraform. In terms of the machines itself I have set things up so I never really need to log into a machine, the machines have health checks to identify whether specific services and files are in place, and if these fail the machines are killed. I know a machine is up properly because at the end of the Chef run the system calls out to a deployment server and so I can see the machine requesting application code and the code going on the server. All very accessible and no interacting with a server rack or network cable! I realise a lot of enterprises are a long way from this, where I work we have an enormous amount of ground to make up in getting other parts of the business on-board with the new technology, and it changes fundamentally the way in which a team works. For example I am having to do a lot of architecture work, as well as work on lower levels of the network stack, for example creating and testing the firewall rules, whereas before I was only working on the server side. I don't know how long I will be able to continue this, as there are lots of changes being proposed, so for now I am trying to learn as much as I can until I have to move. Hope this helps, Andrew. -----Original Message----- From: Blind-sysadmins [mailto:blind-sysadmins-bounces@lists.hodgsonfamily.org] On Behalf Of Ryan Hutchings Sent: 01 April 2017 22:56 To: 'Blind sysadmins list' Subject: Re: [Blind-sysadmins] Access to vmware ESX 5.5 (both gui and VM guest console) Hi Andrew, We do use packer along with kickstart files that are stored on a network server; virtual machines are then instructed to boot from PXE to kick (install os), and then we have a postinstall script executed after the os is installed, which installs puppet and configures iptables, ssh etc after which point I have ssh access and can connect to the machines. However, there are two issues. 1. If the machine fails halfway through kickstart and I need to get onto the machine to see what the problem is, I am unable to, as ssh is not yet setup. 2. When powering the virtual machine one, I am unable to get into the menu that allows one to select "network boot" or "pxe" - this is a vmware option as aposed to a option in the guest itself, and is done by pressing f12 just as the VM is powering on. I tried to see if powershell or ruby vmware cli tools could automate pressing f12 at the appropriate time, but alas, it cannot. I have been thinking of looking into AWS and maybe moving more towards that sideo f things, since that is the future of virtual machine deployment anyway, and seems, on the face of it, to be more accessible. Incidentally, does AWS work well with screen readers? As a note, we use Redhat enterprise Linux 6 at the particular company I am working in at the moment; this does not allow initiating an install via ssh, whereas some distributions of Linux do, such as debian. If I was able to initiate the install via ssh I could monitor the kickstart via that. Thanks, Ryan -----Original Message----- From: Blind-sysadmins [mailto:blind-sysadmins-bounces@lists.hodgsonfamily.org] On Behalf Of Andrew Hodgson Sent: 01 April 2017 21:35 To: Blind sysadmins list Subject: Re: [Blind-sysadmins] Access to vmware ESX 5.5 (both gui and VM guest console) Hi, There is no real way of accessing ESX consoles with speech since they use a graphical representation of the screen. I believe the way forward for us is to use automation as much as possible to get us a working system without having to resort to console access. I realise this is quite a different story in most companies, for example the work I am doing for the people I work for I am in the automation team, which is working in AWS, and completely separate from the rest of the business using ESX with a very different workflow. I am typically using Packer to create images in code, then those are deployed to VMs and I can then use those going forward with SSH or something else. I would recommend looking at Packer with ESX if you can to see if that will help you with your workflow. Andrew. -----Original Message----- From: Blind-sysadmins [mailto:blind-sysadmins-bounces@lists.hodgsonfamily.org] On Behalf Of Ryan Hutchings Sent: 01 April 2017 15:46 To: blind-sysadmins@lists.hodgsonfamily.org Subject: [Blind-sysadmins] Access to vmware ESX 5.5 (both gui and VM guest console) Hi all, I recently joined the list, as I came across it while researching the above subject. I am a Linux system administrator in the UK, and contract out my services to various companies. A few places I have worked in predominantly use virtual machines for their servers, via vmware ESX 5.5. I have found access to both the GUI of vmware ESX (which is done via a web interface which uses inaccessible flash) and Virtual machine consoles themselves, to be nearly impossible to use with a screen reader (have tried both JAWS and NVDA). Supposedly, vmware ESX 6.0 has improved the accessibility of its web interface, but I haven't come across a company who uses ESX 6.0 yet, and the ones that I have worked for that use 5.5 have been reluctant to upgrade because of the perceived risk, virtual machine migration and so on. I have tried using the virtual console on Linux machines and network serial port access on vmware ESX (which I had to get sighted colleagues to setup), but this caused issues for sighted people who then wanted to use machines via the main vmware guest console. This meant that I had to enable serial port access when initially setting up a machine (via kickstart), and then disable the serial port once I had done the setup, both these tasks requiring sighted assistance. Have any of you had experience with using Vmware guest consoles / the vmware ESX 5.5 GUI with a screen reader? I have used vmware workstation and vmware player at home several times to run my own virtual machines, but I was able to access most machines via ssh and telnet. At the compaies I have worked at, ssh/telnet access is blocked for initial kicking of a machine, and is only available once machine configuration is complete. I have also explored using powershell and ruby esx interfaces to ESX via the command line, but these do not allow booting a machine via PXE for example, which is required for initial machine setup using kick start over a network. Many thanks for any advice, Ryan Hutchings _______________________________________________ Blind-sysadmins mailing list Blind-sysadmins@lists.hodgsonfamily.org https://lists.hodgsonfamily.org/listinfo/blind-sysadmins _______________________________________________ Blind-sysadmins mailing list Blind-sysadmins@lists.hodgsonfamily.org https://lists.hodgsonfamily.org/listinfo/blind-sysadmins _______________________________________________ Blind-sysadmins mailing list Blind-sysadmins@lists.hodgsonfamily.org https://lists.hodgsonfamily.org/listinfo/blind-sysadmins _______________________________________________ Blind-sysadmins mailing list Blind-sysadmins@lists.hodgsonfamily.org https://lists.hodgsonfamily.org/listinfo/blind-sysadmins