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