I'm trying to automate the installation process of CentOS7 minimal in VirtualBox. Kickstart file is the solution. I find putting ks.cfg file into OEMDRV.vhdm disk and mounting it to VM memory the easiest way to give the VM access to the configuration file.
Anaconda reads ks.cfg file, as it pointed out mistake in spelling, but once the file is properly written the VM runs an error, same happens if the ks.cfg file is empty:
The I/O cache encountered an error while updating data in medium "ahci-
0-1" (rc=VERR_ACCESS_DENIED). Make sure there is enough free space on the
disk and that the disk is working properly. Operation can be resumed
afterwards.
The host is Windows 10, below is my ks.cfg file. The file is taken of already existing centOS7 minimal VM.
#version=DEVEL
# System authorization information
auth --enableshadow --passalgo=sha512
# Use CDROM installation media
cdrom
# Use cmdline/text/graphical install
graphical
# Run the Setup Agent on first boot
firstboot --enable
ignoredisk --only-use=sda
# Keyboard layouts
keyboard --vckeymap=us --xlayouts='us'
# System language
lang en_US.UTF-8
# Network information
network --bootproto=dhcp --device=enp0s3 --ipv6=auto --activate
network --hostname=localhost.localdomain
# Root password #working on --isctrypted rootpw
rootpw --iscrypted $6$6eqrvzKwp2ST4PMi$VUqUy8G/AsbaZK9XbtqlQcSIZjZ7QQk5yFqe5h/91YwM3GI3PjxEASc062EFPgGjvsmMxcLuKvx8d69KLplYJ1
# System services
services --disabled="chronyd"
# System timezone
timezone Europe/Warsaw --isUtc --nontp
# User
user --groups=wheel --name=secutest --password=$6$Ct923BcyZG.13TR2$jEUcu5tlvncoejaWa9eof.5GL1oU3wLVe0zEWLDrpKY6oXJhGeV4CRvoiYfFeC1IpkPeaXc1z912E3HdvOS/t/ --iscrypted --gecos="secutest"
# System bootloader configuration
bootloader --append=" crashkernel=auto" --location=mbr --boot-drive=sda
%packages
#^minimal
#core
kexec-tools
%end
%addon com_redhat_kdump --enable --reserve-mb='auto'
%end
%anaconda
pwpolicy root --minlen=6 --minquality=1 --notstrict --nochanges --notempty
pwpolicy user --minlen=6 --minquality=1 --notstrict --nochanges --emptyok
pwpolicy luks --minlen=6 --minquality=1 --notstrict --nochanges --notempty
%end
reboot
The solution is to use OEMDRV.iso, ISO disk type. Next OEMDRV disk has to be mounted to VM's SATA controller.
This command creates OEMDV.iso file with volume labeled 'OEMDRV' out of folder, which is exactly what we need.
$ mkisofs -V OEMDRV -o OEMDRV.iso path/to/directory
Related
Due to increasing space consumption of WSL I was forced to move my WSL distros to another disk.
Ubuntu
docker-desktop
docker-desktop-data
I used these commands.
wsl --shutdown
wsl --export (on all three of those distros)
wsl --import (already on another disk)
Now my environment is running fine but the ext4.vhdx in AppData\Local\Docker\wsl\data is still present and I can't remove it due to it still being used.
When I look at process hadnles
Its still being used by system which is not telling much.
If I run WSL --shutdown all virtual disks present on disk E: lose their handles and the one on disk C: is still being used.
Would you know how to find out what part of WSL or if it even is WSL is using?
Since shutting down WSL does not remove that handle it might be used by something else.
Its not docker-for-desktop that one uses different disk.
Thanks for your suggestions.
Docker Desktop for Windows, which uses WSL2, stores all image and container files in a separate virtual volume (vhdx). This virtual hard disk file can automatically grow when it needs more space (to a certain limit). Unfortunately, if you reclaim some space, i.e. by removing unused images, vhdx doesn't shrink automatically. Luckily, you can reduce its size manually by calling this command in PowerShell (as Administrator):
Optimize-VHD -Path $Env:LOCALAPPDATA\Docker\wsl\data\ext4.vhdx -Mode Full
If the above command fails with
The system failed to compact 'C:\Users\Maxx\AppData\Local\Docker\wsl\data\ext4.vhdx':
The process cannot access the file because it is being used by another process. (0x80070020).
exit form Docker Desktop or stop services and tasks using that file:
net stop com.docker.service
taskkill /IM "docker.exe" /F
taskkill /IM "Docker Desktop.exe" /F
wsl --shutdown
I reclaimed 15Gb of 40Gb.
Origin of the solution.
You can just clean data from interface. Troubleshooting -> Clean/Purge data
Upgrading from WSL1 to WSL2 made it a bit messy, but resetting docker-desktop to its default setting and then purging data from WSL (using docker-desktop troublesshot) cleared it for me.
I have modified ”SELINUX=enforcing“ in /etc/selinux/config.But after restarting the machine,I can't ssh to my machine.
Prompt that
/bin/bash: Permission denied
When you edited the SELINUX for the first time or when switching between different types of policy, you need to relabel the filesystem. The below steps will do the relabel process automatically as shown in the procedures:
Restart server
reboot
On the GRUB display, press “e” to start editing the selected menu item.
Perform a break at an early stage of the boot process by typing 「rd.break」 at the end of the line starting
with kernel=.
kernel=... UTF-8 rd.break
Once ready press CTRL+X to start the boot process.
Check write access on the /sysroot mount point. By default this mount point is mounted only with the read-only (ro) access
mount | grep sysroot
=/dev/mapper/rhel-root on /sysroot type xfs (ro,relatime,attr2,inode64,noquota)
Remount the sysroot directory with read & write access.
mount -o remount,rw /sysroot
mount | grep sysroot
=/dev/mapper/rhel-root on /sysroot type xfs (rw,relatime,attr2,inode64,noquota)
Enter chroot system
chroot /sysroot
(new prompt) sh-4.4#
Force file-system relabeling. Next time when you will reboot the system, it will relabel the filesystem for
SElinux automatically.This usually occurs when labeling a file system for SELinux for the first time, or when
switching between different types of policy, such as changing from the targeted to the strict policy.
touch /.autorelabel
Exit the chroot. Reboot the machine
exit
logout or reboot (it will take time)
Now you should be able to login with ssh.
I am facing the problems when restoring the "/" partition into the newly centos. My plan is to restore the backed-up centos (which has few packages installed like openstack) into a new machine.
The restore process goes as part of PXE boot. I have got some kind of kickstart files which does the stuff.
My PXE is in the order
Install some packages before CENT OS
Install CENT OS
Copy the backed-up "/" data into "/" on latest
Unfortunately, the new Cent OS is not starting going into Emergency mode and asking me to press Ctrl+D.
Any help is really great !!
I am using rsnapshot for backup the Cent OS stuff. I have to exclude some directories in order to make it work after restoration of Cent OS.
Here is my rsnapshot.conf file changes.
backup root#192.168.0.1:/ remote-backup/ exclude=/proc,exclude=/sys,exclude=/boot/grub,exclude=/boot/grub2,exclude=/etc/fstab,exclude=/etc/sysconfig/network-scripts/
The above backup is with root. Make sure you exclude those specified directories. Otherwise system doesn't boot up.
rsync for restore (in the Kickstart file)
echo "Restoring snapshot *TEST*"
rsync -avr --rsh="sshpass -p mypassword ssh -o StrictHostKeyChecking=no -l root" 192.168.0.2:/.snapshots/alpha.0/remote-backup/* /
Exluding them is the key here. Followed this link https://www.serverpronto.com/kb/page.php?id=Backing+Up+and+Restore+Your+Server
I have a OVA file(MyOvafile.ova) which contain MemorySize=16GB and CPU count=4.
I have deployed the Ovftool on VMware ESXi server.
I am using the following command to deploy the VM:
/vmfs/volumes/DataStore1/vmware-ovftool/ovftool --memorySize:15360 --name=Test_VM -dm=thin -ds=DataStore1 /vmfs/volumes/DataStore1/OVA_V5.1_BSI-8/MyOvafile.ova
Now the problem i am facing:
As i am giving MemorySize of 15360MB but after deployment VM has the same values as defined in ova file (MyOvafile.ova i.e 16GB)
My Question:
How can i change the value of MemorySize and CPU count through ovftool command?
Apparently, this seems a bug in OVFTOOL (and documentation as well).
CPU and memory cannot be overridden by OVFTOOL's corresponding parameters.
However, there is hack by modifying it in VMX file of VM (and then using reconfigure command).
1) Get VMXfile Location (ending with .vmx) :
vim-cmd vmsvc/getallvms
Vmid Name File Guest OS Version Annotation
72 Test_vm [datastore2] VM_name/VM_name.vmx rhel6_64Guest vmx-08
2) Modify vmx file (for example, using awk) for changing 'vCPUS=REQ_CPUs' entry.
3) Reconfigure .vmx file
vim-cmd vmsvc/reload <VM_ID>
Issue reported in VMware community: https://communities.vmware.com/message/2698710#2698710
In the Docker best practices guide it states:
You are strongly encouraged to use VOLUME for any mutable and/or user-serviceable parts of your image.
And by looking at the source code for e.g. the cpuguy83/nagios image this can clearly be seen done, as everything from nagios to apache config directories are made available as volumes.
However, looking at the same image the apache service (and cgi-scripts for nagios) are run as the nagios user by default. So now I'm in a pickle, as I can't seem to figure how to add my own config files in order to e.g. define more hosts for nagios monitoring. I've tried:
FROM cpuguy83/nagios
ADD my_custom_config.cfg /opt/nagios/etc/conf.d/
RUN chown nagios: /opt/nagios/etc/conf.d/my_custom_config.cfg
CMD ["/opt/local/bin/start_nagios"]
I build as normal, and try to run it with docker run -d -p 8000:80 <image_hash>, however I get the following error:
Error: Cannot open config file '/opt/nagios/etc/conf.d/my_custom_config.cfg' for reading: Permission denied
And sure enough, the permissions in the folder looks like (whist the apache process runs as nagios):
# ls -l /opt/nagios/etc/conf.d/
-rw-rw---- 1 root root 861 Jan 5 13:43 my_custom_config.cfg
Now, this has been answered before (why doesn't chown work in Dockerfile), but no proper solution other than "change the original Dockerfile" has been proposed.
To be honest, I think there's some core concept here I haven't grasped (as I can't see the point of declaring config directories as VOLUME nor running services as anything other than root) - so provided a Dockerfile as above (which follows Docker best practices by adding multiple volumes) is the solution/problem:
To change NAGIOS_USER/APACHE_RUN_USER to 'root' and run everything as root?
To remove the VOLUME declarations in the Dockerfile for nagios?
Other approaches?
How would you extend the nagios dockerfile above with your own config file?
Since you are adding your own my_custom_config.cfg file directly into the container at build time just change the permissions of the my_custom_config.cfg file on your host machine and then build your image using docker build. The host machine permissions are copied into the container image.