| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change is to ensure the existing users will exist after an
upgrade. Otherwise, if there are merge conflicts when upgrading,
the users will be lost and the root password will be deactivated.
If that happens and the only way to access to the system is
through ssh and the system was rebooted after the upgrade (manually
or automatically) then the system won't be accessible anymore.
This change also means that we can no longer make changes to the
base /etc/passwd or /etc/group in the 'fhs-dirs' chunk without adding
a manual hook to add the new users/groups when upgrading old systems.
In the following link is the email thread where was discussed this issue:
http://vlists.pepperfish.net/pipermail/baserock-dev-baserock.org/2014-March/004581.html
|
| |
|
|
|
|
|
|
|
| |
Since with 'system-version-manager' is possible to change
the default system, 'baserock-system-config-sync' shouldn't
get the default system, and get an extra parameter to choose
the system version to merge.
|
|
|
|
|
|
|
| |
When one file is present in v1 and in vUser, and is not present in
v2, baserock-system-config-sync copies vUser version of the file.
This was happening before this commit, but it was wrong explained
in the behaviour table.
|
|
|
|
|
| |
If a file was removed in vUser, and v2 doesn't have a new one,
then the file is not longer needed.
|
|
|
|
|
|
|
| |
When vu == v2, the script tried to reverse the patch. Now this
won't happen again.
Also added '-f' flag calling 'patch' to prevent also reverse patching.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
baserock-sytem-config-sync:
Changes here are caused by a bug found in GNU patch
managing the permissions of the files when using the
patch command like:
patch <file_to_apply_patch> -t -o <output_file>
To reproduce the bug:
echo foo > file1
echo bar > file2
diff -u file1 file2 | patch 1 -t -o file3
ls -l
You can check that the permissions of 'file3' are different
than the permissions of 'file1' or 'file2'.
To avoid the bug, this patch changes the way we are using
patch, using it as following:
patch <file_to_apply_patch> -t
Since the output file is not specified, the output file will
be the file in which we want to apply the patch. And
due we cannot specify the output file, we are copying
the file to the destination directory, and then applying
the patch there.
As a consequence of changing the way of using patch, now
'patch' generates an extra file when patching fails. This
file is added in the test suite also in this commit.
|
|
|
|
| |
name, and explicitly ask for a unified diff
|
| |
|
|
|
|
|
|
|
|
|
| |
Tests will now be handled by a test suite in a future commit, so this
mode will not be needed anymore. The test suite will work by replacing
the mounting script by a fake mounting script that points to a directory
with a systems folder.
Also add trap again, now that it is more tested.
|
|
|
|
|
|
|
|
|
|
|
| |
- Check if file is the same kind in all versions before attempt to patch
it.
- Use the batch mode in patch command, as the script will be executed
remotely
- Remove the use of the trap for now. It was not well test and it was
causing the old directories to not be removed.
|
|
This commit adds a script to merge and syncronize /etc in different system versions.
The first argument read from command line is the mode, which can be one
of the following:
- test: the purpose of this mode is to test some merge cases. It
receives from the command line v1_dir, vu_dir and v2_dir and
vt_dir. The meaning of these arguments is explained in the
script.
- merge: merges the user changes in /etc in the run system of the
version given as argument
- sync: syncronizes /etc in all run versions, so that this directory is exactly
the same as the version given as argument.
This commit also includes an auxiliary script to mount the systems directory in a
give directory given as argument, and some testing folders to use with
the test mode.
|