I think a reconfiguration of the SME-server changes the selintra-database. That is something that shouldn't happen.
It's a little more complex. Here is how it works...
An SME server reconfig (for example, post-upgrade) will usually run the fragments in the
migrate tree (in
/etc/e-smith/db). Sail-2.x has a migrate routine in that tree. When it runs it will first delete the keys in the file
/home/e-smith/db/selintra-delete from the selintra database. It will then attempt to add the rows in
/home/e-smith/db/selintra-update. Now, because the SME database only allows unique keys, it is safe to repeatedly apply
/home/e-smith/db/selintra-update because it can't add the same row twice (the SME database won't allow it). Also because we have a delete/add couple; then by deciding what we put in each, we can keep the selintra database up to date.
Unfortunately, frifri, by removing only the features
update row, you may have caused yourself a small problem. The next time the SME reconfigure runs on your system it will delete the features.conf entry (see
/home/e-smith/db/selintra-delete) but now, it will not add it back because you have removed the update row.
Now, you have correctly identified this as a bug because we should not be repeatedly cleaning this record because, as you say, users should be allowed to change it for themselves. However, the correct way to remove the restraint is to remove the key from the
selintra-delete file and leave the row in the
selintra-update file. In this way, it will be added to systems where it doesn't exist (i.e. new systems) but it will not change systems where it does exist.
Thankyou for reporting this error and I hope my explanation is clear.
Kind Regards
S
8 Replies
2017 Views