Hi list, While 90% of our users are out of the office, I’ve found time to sit down with and look further at running Chef 11 as an unprivileged user. After hours sitting with the like of Process Monitor, I still can’t understand why chef is unable to manipulate the permissions on files for which the current user has full control and is the owner. The failure is when attempting to read the security descriptor of the destination file so that they can be replicated to the new template; the API call is denied by Windows, although icacls is able to make the same call and succeed. I think it must be related to the application compatibility/virtualisation layers, but I can’t find any setting that will change the behaviour – if indeed there is one! So I decided to work around the problem and write a new provider that wouldn’t attempt to perform permissions manipulation in the problematic cases. However, in doing so found the file_atomic_update setting. Setting this to false causes Chef uses the Cp provider, which “just works” for the use cases in which I am interested (generating client side configuration files on a per-user basis), as it doesn’t attempt any permissions manipulation unless explicitly specified in the resource. FYI, I also had problems with the Directory resource, which I just replaced with calls to Dir.mkdir(). Thanks for your replies, and my apologies for the very delayed feedback. Onwards to Chef 11! Dan. From: Adam Edwards [mailto:
Hello Dan – there aren’t any changes from chef-client 10 to chef-client 11 that should affect Windows unprivileged users. There *is* a warning however that you may see in log output indicating that you’re better off running with full privileges. So if things worked for you with chef-client 10, they will probably work fine on chef-client 11; if that is indeed true for you, you can ignore the warning in the logs, which is aimed at unblocking people who hit issues that could be fixed by running with full privileges. That said, as Kevin suggests, there are a lot of things that won’t work in you don’t have full privileges – this is due to restrictions (correctly) built in to Windows, not really a limitation in Chef – chef-client won’t allow the security model of Windows to be circumvented. For example, if you have a recipe that adds a new user to a Windows system, that recipe will fail unless chef-client is executed as a user with full privileges. The “fix” is to run with full privileges, or since its Windows, configure the system / user account such that it has exactly the privileges you need for your specific recipes to succeed. -Adam First of all, you mention that you are migrating from Chef 10 to Chef 11. Are you talking about migrating the server, or the client? Migrating the server really shouldn't make a difference; migrating the client might. My best guess is that the permission problems aren't with the final file location, but rather with the Chef cache directory (or one of the other directories the Chef client uses). It is also possible that the problem arises because Chef doesn't actually create the file, but move it. Chef actually doesn't create templatized files in place. Rather, it builds the templatized files in a temporary location (I think it's actually the cache directory, but I'm not sure off the top of my head), computes the file hash, and then computes the hash of the existing file (only if a file already exists, of course). If the two hashes don't match, Chef then moves the file from the temporary location to its final place. Generally, Chef was not really designed to run with limited permissions. I'm actually impressed that you manage to run it to set up per-user configurations; it's something I'd also love to be able to accomplish! Kevin Keane The NetTech 760-721-8339 Our values: Privacy, Liberty, Justice See https://www.4nettech.com/corp/the-nettech-values.html
|
Archive powered by MHonArc 2.6.16.