Every large deployment has the odd Windows node; well, not every deployment, as many places have Windows-only environments. The reason is quite simple: most closed-source SDKs do not run on anything but Windows, so one needs to write a Windows service to access those functionalities. Fortunately for command-line gurus, Microsoft has created an extraordinary toolset, the PowerShell.
When coding something in PowerShell, one must remember 2 things:
-
The script files should end in .ps1 rather than .bat (and one must usually override a security setting to get the system to run them);
-
Most tasks are one-liners.
Coming from Linux scripting some things may look odd (e.g. it is not possible to directly move directories, one must copy them recursively and then delete the source) but in the end the job gets done. I have put below a few basic tasks that one may at some point need to perform.
1. Getting a zip file from some http server and unzip it:
$source_file = "http://internal.repo/package/module.zip" $tmp_folder = "C\Temp" $dest_folder = "C:\Program Files\Internal\Application" $source_file_name = [io.path]::GetFileNameWithoutExtension($source_file) $dest_zip = "$tmp_folder\$source_file_name" New-Item -ItemType Directory -Force -Path $temp_folder Invoke-WebRequest $source_file -OutFile $dest_zip New-Item -ItemType Directory -Force -Path $dest_folder Add-Type -AssemblyName System.IO.Compression.FileSystem [System.IO.Compression.ZipFile]::ExtractToDirectory($dest_zip, $dest_folder) Remove-Item -Path "$dest_zip" -Force ### No -Force for the temp folder Remove-Item -Path "$tmp_folder"
Who likes interviews? Me neither. Well, depends…
If you get any of the following questions during an interview then either the interviewer did read this one or he’s getting info from the same sources as I am. Either way, let’s get one step forward.
Question 1:
Suppose you log into a node and find the following situation:
# ls -la /bin/chmod rw-r--r-- 1 root root 56032 ian 14 2015 /bin/chmod
Is it fixable?
… yes. Most of the time. Let’s remember how the executables are being started on Linux: with a system loader, ld-linux-something. Let’s check:
# ldd /bin/chmod linux-vdso.so.1 => (0x00007ffdf27fc000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb11a650000) /lib64/ld-linux-x86-64.so.2 (0x00007fb11aa15000)
OK, got it:
# /lib64/ld-linux-x86-64.so.2 /bin/chmod +x /bin/chmod
Fun, isn’t it? The follow up question obviously is “what if the loader’s rights are unproperly set” or something similar. The answer to that is that not all the filesystem issues are fixable with easy commands. One may even have to mount the file system on a different installation (e.g. from a Live CD or attach the virtual storage to another, “good” node) and fix things up from there.
… is ignoring the run order of the scriptlets. Because you may want to arrive to a result close to this one:
-
When installing the rpm for the first time, add the service to chkconfig and get it in the running state;
-
When removing (for good), stop the service and remove it from chkconfig;
-
When upgrading, stop the current running service, do the binary upgrade and start the new service (do not alter chkconfig).
A quick approach to this would ignore the upgrade part completely, hoping that coupling together the removal and the installation would do the trick. Something like the following in the .spec file:
%post chkconfig --add mywow service mywow start %preun service mywow stop chkconfig --del mywow
This will actually do the job if installation and removal of the rpm package were the only operations to be considered. The problem is that during an upgrade this will go horribly wrong as the scriptlet running order is different than the one expected by the previous sample:
-
%pre of the new package
-
%post of the new package
-
%preun of the old package
-
%postun of the old package
The obvious result is that an upgrade with those scriptlets will leave the service stopped and out of chkconfig. A real disaster.
The solution is to look for the first parameter that gets passed when running each scriptlet. The rpm program passes a certain value to indicate if it’s an installation / removal or an upgrade. Considering that value we can write some better scripts:
%post if [ $1 -gt 1 ] ; then service mynow restart else chkconfig --add mywow service mywow start fi %preun if [ $1 -eq 0 ] ; then service mynow stop chkconfig --del mywow fi
Fixed. Now we are good with this.
Hope you enjoyed it!