On Tue, Oct 27, 2015 at 10:01 AM, Mark D. Baushke <m...@juniper.net> wrote: > Dmitry Kasatkin <dmitry.kasat...@gmail.com> writes: > >> On Tue, Oct 27, 2015 at 12:36 AM, Mimi Zohar <zo...@linux.vnet.ibm.com> >> wrote: >> What I just ask is when we can get concurrent writers? >> >> I think system is updated by updating image or packages. > > Accretion of new packages and or updating those new packages is one > thing that a delegated tenant may choose to do. > >> In the first case policy update comes with the new image and loaded on >> reboot. > > The hope is that the reboot will never NEED to happen, but may always be > scheduled and planned well ahead of time. > > Some boxes may get a schedule to do a PM on the hardware, which is all > hot-swapable redundant hardware. Barring upgrades for new features, it > may be expected that a stable system could be running without the entire > system being rebooted for multiple years. > > When the intent is high availability, a five nines means that the box > may onely be unavailable for .001% of the time, which translates to 5.26 > minutes per year. Granted, a scheduled outage does not count against > that time, but given how much work these devices are supposed to be > doing, taking them offline for a few minutes to reboot can lose a lot of > money. > >> in the second case, keys, policy and software comes with packages. >> Before new software (signed with new key) can be used, keys and policy >> needs to be loaded. >> The order is important - first keys, policy, then software can be >> installed and used. >> >> Packages are usually installed in ordered manner (not concurrently). > > Actually, it is entirely possible that an administrator will kick off > multiple concurrent operations to help minimize the downtime that a > system may have for a big upgrade. >
Hi, I understand your point, though this usually not the case in reality. When system updates rolled out, they are tested that nothing breaks along update process. So I do not think that multiple concurrent updates will usually happen. Update process must be reproducible and reliable. But this so minor thing and as you said it makes it a bit "user-space" friendlier, so there is no point to resist ;) BR, Dmitry >> Basically policy writing will happen also in ordered manner. > > That may be a hope or a gaol, but I do not believe it will not always > match observed reality. > >> So what I claim, is that there are no concurrent policy writers. > > It is a very nice world that allows you to make such a claim. > The truth may not always match that world view. > >> Or I am totally wrong? > > You are not totally wrong, some places may follow that path. > > That said, if an administrator actually gets to schedule a thirty-minute > down time to actually do a reboot of the system as well as add new > packages and policies, it seems likely that they will try to do as much > in parallel as possible. This is often seen as being done with scripts > that are broken into multiple operations that may happen in parallel. > So, it is against this 'urgency' of doing a large number of system > upgrades and new package additions that one may need to protect > concurrency. > > I hope this helps. > > -- Mark -- Thanks, Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
