To display the Linux operating system version execute the command
cat /etc/*release* uname -a
Knowledge Base for IT Professionals, Teachers and Astronauts
To display the Linux operating system version execute the command
cat /etc/*release* uname -a
There are many tools to copy files between Windows and Linux computers, I have found this method the simplest.
It does not require any software installation on the Windows machine, and only one package installation on the Linux machine.
Share a folder on the Windows machine and allow access to it for a user. If the Windows computer is in the Windows domain, the domain user does not have to be a member of any security group on the Windows machine.
If you copy files from Windows to Linux, make the folder read-only for the user. If you copy files to the Windows machine, allow write access to the folder for the user.
sudo yum install cifs-utils
sudo apt-get install cifs-utils
mkdir /tmp/windows
sudo mount.cifs '\\WINDOWS_SERVER_IP\attachments' /tmp/windows -o domain=MY_DOMAIN,username=MY_USERNAME,password=MY_PASSWORD,vers=1.0
First, you will be asked for the root password on the Linux machine.
If you do not specify your password in the line above, you will be also asked to enter your password on the Windows machine.
cd /tmp/windows
ls -al
If you get the error message when you issue the mount command
mount error(16): Device or resource busy
try to unmount (umount !) the share first and try the mount again
umount /tmp/windows
The user-specific settings in the Windows registry are stored under the HKEY_CURRENT_USER key. If you open the Regedit.exe application the HKEY_CURRENT_USER key contains the settings for your user account.
To access the registry keys of another user we need to
Another Security ID list location:
The partial list of the Security IDs is also available at
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList
Not all user profiles are listed here.
Click the Security ID folders on the left to see the username in the ProfileImagePath.
AWS changed how Windows Server EC2 instances send messages during boot.
Windows Server 2012 R2 AWS EC2 instances sent the “Windows is ready” message every time those became available after boot.
When a Windows Server 2016 AWS EC2 instance launches, it only sends the “Windows is ready” message during the first boot. If you create your custom AMI with Packer, the first boot happens during the Packer AMI creation, so Chef Test Kitchen does not receive the expected message and the process times out with the message
>>>>>> Ran out of time waiting for the server with id [i-… to become ready, attempting to destroy it
EC2 instance <i-…> destroyed.
To configure Windows Server 2016 instances to send the expected “Windows is ready” message during every boot, add a PowerShell line to your Packer template that creates your custom AMI:
{ "type": "powershell", "pause_before":"2s", "elevated_user": "MY_ADMIN_USER", "elevated_password": "MY_ADMIN_PASSWORD", "inline": [ "C:\\ProgramData\\Amazon\\EC2-Windows\\Launch\\Scripts\\SendWindowsIsReady.ps1 -Schedule" ] },
This code creates a scheduled task to execute the configuration script on the instance.
More information is at https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2launch.html#ec2launch-sendwinisready
When you use a virtual machine to write your Chef cookbooks you may want to test them locally with Vagrant.
This nested virtual machine cannot use a 64 bit operating system, because to run a 64 bit virtual machine, the host computer’s CPU has to provide the CPU Extensions. Currently only physical CPUs can provide the CPU Extensions, no virtualization software can do that.
The Chef Test Kitchen uses Vagrant to launch test instances. In the background Vagrant uses the VirtualBox engine, so your virtual workstation needs to have Vagrant and VirtualBox installed.
To make sure TestKitchen uses the 32 bit operating system first we will set up the 32 bit virtual machine in Vagrant.
vagrant init hashicorp/precise32
vagrant halt
vagrant global-status
The result looks like this:
id name provider state directory ---------------------------------------------------------------------------------------------------------------------------- 21590cd default virtualbox running C:/Users/interview/Documents
vagrant halt 21590cd
driver: name: vagrant network: - ["forwarded_port", {guest: 2200, host: 2222}] - ["private_network", {ip: "127.0.0.1"}] platforms: - name: hashicorp/precise32
kitchen converge hashicorp-precise32
There can be reasons when we want to run a VirtualBox virtual machine on another VirtualBox virtual machine.
I am setting up a Windows virtual machine to interview job candidates and want to run a small Ubuntu virtual machine on the Windows virtual machine. It is not recommended for performance reasons, but I want to set up a base interview machine that I can wipe and recreate any time for the next candidate.
Besides the performance hit there is one more rule: the nested guest operating system needs to be 32 bit.
Even if you have a 64 bit workstation, and run a 64 bit guest operating system on it, the VirtualBox on the guest operating system can only host 32 bit guest-guest operating systems, because for a 64 bit operating system to run, the host machine needs to have the CPU Extension feature turned on. Currently only physical CPUs have the CPU Extension feature, so even a 64 bit guest virtual machine cannot provide it.
When your VirtualBox virtual machine’s hard drive fills up Virtual Box does not provide a user interface to extend it. If you run VirtualBox on a Macintosh workstation
~/VirtualBox VMs
$ cd /Applications/VirtualBox.app/Contents/Resources/VirtualBoxVM.app/Contents/MacOS
VBoxManage showhdinfo ~/VirtualBox\ VMs/Win\ 10/Win\ 10.vdi
VBoxManage modifyhd --resize 100000 ~/VirtualBox\ VMs/Win\ 10/Win\ 10.vdi
UMG/Win\ 10\ UMG.vdi
0%…10%…20%…30%…40%…50%…60%…70%…80%…90%…100%
(Exclamation point at the end of the method name)
There are methods that have a permanent or dangerous version. The exclamation point designates to use the dangerous version of the method.
The bang versions of the string manipulation methods (with the exclamation point), modify the string variable in place. Some of these methods are
The original string ‘gsub’ substitution method:
original = 'My old cat' new = original.gsub('old', 'new') results: original = 'My old cat' new ='My new cat'
The dangerous (bang) ‘gsub’ method with the exclamation point modifies the original variable:
original = 'My old cat' original.gsub!('old', 'new') results: original = 'My new cat'
The script exits with Kernel::exit
, but Kernel::exit!
causes an immediate exit, bypassing any exit handlers.
The AWS account number uniquely identifies the AWs account you are working with. All AWS “arn” identifiers contain it, and you need to know it when you want to share AMIs with other accounts.
If there are no resources created yet in the account, you can find the account number in the “arn” of your user account.
Terraform is a very powerful, free command-line tool to launch servers in any cloud or virtual machine environment. Hashicorp, the creator of Terraform just introduced the paid Terraform Enterprise server, that orchestrates the execution of the Terraform scripts.
Octopus is another tool that added Terraform orchestration functionality in version 2018.3
In this example, we will set up a Multi-Tenant Octopus project to launch servers in AWS with Terraform scripts and configure them with Chef.
GitHub is the most flexible way to store the Terraform scripts. Octopus can download and execute the same script in multiple Octopus projects. This eliminates the code duplication and makes the scripts available for execution from the command line.
If the GitHub repository is private, Octopus will need a way to access it with a username and password.
Tag the source code version, Octopus needs a version to refer to the version of your script
git tag 1.0.0 git push --tags
We will create a Multi-Tenant Octopus project to be able to use the same Octopus project for multiple server types in multiple AWS environments.
We will create
The lifecycle governs how the project is promoted between environments.
The project group holds your launch projects together.
This feed will allow Octopus to connect to GitHub
AWS accounts store the credentials to connect to Amazon Web Sevices
Store your private keys in Octopus, so you can reference them in your variables.
The project contains the reference to the Terraform script to launch the server, the connection to the GitHub repository where the Terraform script is stored, and credentials to access the AWS account. The Terraform script and GitHub connection are going to be the same for every server launch, but the AWS account credentials have to be different for each AWS account. If you work with multiple AWS accounts, you need to create separate projects for each AWS account.
When we added prefixes to the project variables to show which component is responsible for setting it, we have changed the variable name. Update the Terraform script to reflect it.
ami = "#{os.instance_ami}"
There are values that are different for each operating system in each AWS account.
The AMI ID depends on the operating system and the application environment. We can test the new version of the operating system in the development environment, while we are still launching servers with the old, tested version for production.
The common, OS-specific security group ID is different in every AWS account. It depends on the AWS account and the operating system.
To be able to set the value of this variable based on the OS and the AWs account, or the OS and application environment, we need to create an OS-specific project that passes in the appropriate variable values to the generic project.
Set the OS-specific variables in the OS-specific child project. To avoid variable name collision later add the parent.prefix to the variables passed in from the child to the parent project.
Library Variable Sets specify the variables that have to be set in a higher level component, like a tenant, environment, and target.
Add the Library Variable Sets to the OS-specific project, so the tenants can set them with the instance-specific values.
The child project can pass variables into the parent project. Select the variable to pass into the parent project. You need to do this in every child project that calls the common parent project.
Tenants are server types that use the same Octopus project. A tenant can be an application or a software development project where the servers share common attributes and run on the same operating system type, like all Linux, or all Windows, so the same Terraform script can launch them.
Tags help you to organize your tenants.
Deployment targets are the servers we are launching. In enterprise settings, all servers have a standardized name that conforms to the company standards.
If there was a change in the parent project, we need to create a release for the parent project and all child projects that call it.
git tag 1.0.0 git push --tags
The Octopus project release is tied to a specific Git tag (release). When we change the Terraform script in the Git repository we need to
git tag 1.0.12 git push --tags
To pass in a new Chef attribute from the Tenant
{ "set_hostname": "#{host.set_hostname}", "agent_name": "#{host.agent_name}", "add_to_domain": "#{host.add_to_domain}" }
To save the variable values to the log add the following two variables to the project
OctopusPrintVariables | True |
OctopusPrintEvaluatedVariables | True |
For the change to take effect
or
More info at https://octopus.com/docs/support/debug-problems-with-octopus-variables