Base image wrap up
- Review configuration
- Was there anything else that you wanted to adjust?
Check some common network settings
If any changes were made to subnets, make sure that /etc/hostname.
file(s) have been appropriately updated.
- If any changes were made to subnets, make sure that /etc/ntpd.conf.privsvr may also need appropriate updates. (The /etc/ntpd.conf.local filesystem object should be a “soft”/symbolic link to the /etc/ntpd.conf.privsvr file, if this guide has been getting followed.)
- Check the “name resolution” configuration (in the /etc/resolv.conf file. Having that file point to public servers isn't a bad idea: DHCP/IPv4 will presumably override for most systems. Having that file point at an invalid subnet, which is unlikely to be getting legitimately used (because there are no plans to place an authorized DNS server in that subnet) is less ideal.
- If any changes were made to subnets, make sure that /etc/hostname.
And, in case this gets done multiple times, a cumulative record will store all of the commands that get saved.
- Update file integrity checking data
- Newer approach
- Older approach
Just shortly before creating a child image, the situation is a sensible spot to update the file integrity checking data. This will typically allow child images to have a relatively easy way to see what changes were made since a child image was created.
- Checking out the results
Recommended: Go ahead and view the latest AIDE report:
Viewing the AIDE report (with “
- (older method: Viewing the AIDE report)
Previously, this guide may have recommended viewing the AIDE report just to see what an AIDE report looks like. However, take some time with this task. Don't just look at it, see “there is a report!”, and move on.
Look at what files the report shows as being modified. Do those files seem familiar? Hopefully, a lot of them do, because they are files that were modified by the earlier steps in the project. This report may be much more meaningful than some of the earlier reports.
Think, for just a moment, how that could be useful:
- If an automated attack, using a computer virus, changed some files, a report like this could help to highlight what got changed
- If a person intentionally attacked the system, a report like this could help to highlight what got changed
- If a well-meaning administrator made some changes that had an unexpected side effect, a report like this could help to highlight what changes have occurred
This can help to identify “back doors” that were made.
- Viewing the AIDE report (with “
- Adding a symlink
- Recommended actions
Current recommendation: skip this. This is now done as part of running
with another parameter, reducing the need for such a process that took additional time and enough disk space for another (if all steps were performed) database.
- Older process
I also like to name the database something rather notable, to distinguish this database from other databases that may have been created at less noteworthy/prominent times.
- Getting picky
Of course, doing so will then cause the extra file to show up in future reports; that can be worked around by simply repeating the process (update the database yet one more time, and rotate the files).
Yes, that seems rather time consuming and redundant for what is really a very minor benefit. However, it results in a nicer “parent” image. As long as you don't end up needing to adjust an existing parent image (again) at a later time, the investment will result in a nicer product that may remain for a while.
- Newer approach
After following the instructions above, to create the symlink, run:
- Older approach
If is the opinion of the author of this text that the end result is nicer, slightly, because then a file integrity check on a child image doesn't report the manually-created symlink that was just made on the parent image. However, this is a rather time-consuming way to make a change that is really quite small. Many people might understandably elect to simply skip making yet another “file integirty check” database update over this admittedly rather insignificant topic.
- Optimize a volume
Note that this isn't a step that is necessarily recommended. Often, the results may simply be mostly an unbeneficial waste of time. Just as a guideline (rather than a strict rule that is necessary), this guide does not recommend wasting time worrying about trying to perform defragmentation for Unix-style partitions, including FFS/UFS (found on BSD-based systems), Ext2 (found on systems using the Linux kernel), or newer popular filesytem types that are popular by users of the Linux kernel (like ZFS or BtrFS). Performing such an optimization may be more sensible for FAT or NTFS partitions. However, on a brand new machine, there is probably little fragmentation yet, which may cause a defragmentation effort to be mostly pointless (even on FAT or NTFS partitions).
So, this guide is not making a strong recommendation to spend resources (notably: time) trying to perform some sort of optimization process.
However, what is being recommended is that any optimization should be done at a sensible time, like this point of the process. If a volume is going to go through an optimization process, such as defragmentation, then doing so to the parent image is probably more sensible than leaving the parent unoptimized (and then needing to re-perform certain optimization-related tasks on every child image that gets created). So:
- the first recommendation is to not bother with optimizing
- However, if that recommendation is not being followed, then the recommended process is to get the optimization process performed now.
If any optimization is desired, then:
- Optimizing is not considered to be part of this guide. So, any directions/references/resources are not currently considered to be part of this guide.
- optimizing a volume (e.g. defragmenting) discusses performing such optimizations.
It seems likely that the “file integrity checker” software might not notice any change caused by the disk optimization process. (The logical structure wouldn't need to change, and the files' data streams should contain the same data.) However, if the file integrity checks do notice file piece locations being altered, the optimization process might create a huge report. For this reason, it may be good to update the file integrity checker databases after the optimization is complete. That way, the huge report will be expected, and can be acknowledged (and quickly set aside) while the large report is less alarming.