smb.conf template evaluated twice about samba HOT 20 CLOSED

generally i'd suggest that nothing should be attempting to create that resource without going through the accumulator pattern of: using edit_resource, root run_context, action nothing, plus delayed_action.

which explains why "this seems to work if we add action :nothing to the samba_server template, and delayed_action :create to the resources."

although i don't think that goes quite far enough.

from samba.

Thanks.

this is one for Chef/Chef. I've raised a bug at chef/chef#5828

from samba.

I wasn't sure it was really a Chef bug so raised it here. Thanks!

from samba.

No problem. It's an edit_resource bug imho. The accumulator pattern is a bit of a tricky one to piece together. I was hoping this would work!

from samba.

The end output looks, and is correct.

But it's not correctly evaluating the content.
I'm expecting it to
Accumulate all resources
samba_server "server"
samba_share "share1"
samba_share "share2"

Check the content against what's been compiled. It seems to be doing it in two stages.

check file
Fix file to defaults

samba_share "share1"
samba_share "share2"
check file
Fix file to correct state

from samba.

Isn't this just due to the assignment here:

https://github.com/sous-chefs/samba/blob/master/resources/server.rb#L64-L76

You have to do the merging there just like here:

https://github.com/sous-chefs/samba/blob/master/resources/share.rb#L42-L50

from samba.

@lamont-granquist except the first resource isn't an edit resource, but declaring the resource. Which we then later edit.

And with putting them both in the root run_context (if there's a more sane way I've love to hear it!) they find each other, but Chef is still treating them as two separate resources.

On a second run it does this:

* template[/etc/samba/smb.conf] action create
           - update content in file /etc/samba/smb.conf from 7c6796 to bcd111

 * template[/etc/samba/smb.conf] action create
           - update content in file /etc/samba/smb.conf from bcd111 to 7c6796

from samba.

Minor update, this seems to work if we add action :nothing to the samba_server template, and delayed_action :create to the resources.

It's still giving me cloning warnings though. So I don't believe it's truly fixed and requires the samba_share to be declared if you want the smb.conf on disk

from samba.

i'm not seeing any samba::default recipe in this cookbook?

  Cloning resource attributes for template[/etc/samba/smb.conf] from prior resource
Previous template[/etc/samba/smb.conf]: /home/jamiez/chef-home/local-mode-cache/cache/cookbooks/samba/recipes/default.rb:11:in `from_file'
Current  template[/etc/samba/smb.conf]: /home/jamiez/chef-home/local-mode-cache/cache/cookbooks/samba/resources/server.rb:58:in `block (2 levels) in class_from_file' at 1 location:
    - /home/jamiez/chef-home/local-mode-cache/cache/cookbooks/samba/resources/server.rb:58:in `block (2 levels) in class_from_file'
   See https://docs.chef.io/deprecations_resource_cloning.html for further details.

that certainly looks incorrect and the accumulated resource(s) should be responsible for adding the resource to the outer run_context as action :nothing and firing off the delayed action.

if you're also declaring it in the outer run context via a normal recipe, then its expected that you'd get two resources with the same name in the resource_collection since you'd get one from the recipe and one from the declaration in the samba_server resource -- then since you have two resources its not too surprising they'd get into fights.

from samba.

The default recipe thing is rather odd. As I've removed it.

But I'm still getting that error from a test recipe e.g. running kitchen verify centos-68 from this cookbook.

        Cloning resource attributes for template[/etc/samba/smb.conf] from prior resource
       Previous template[/etc/samba/smb.conf]: /tmp/kitchen/cache/cookbooks/samba/resources/server.rb:58:in `block (2 levels) in class_from_file'
       Current  template[/etc/samba/smb.conf]: /tmp/kitchen/cache/cookbooks/samba/resources/server.rb:58:in `block (2 levels) in class_from_file' at 1 location:
           - /tmp/kitchen/cache/cookbooks/samba/resources/server.rb:58:in `block (2 levels) in class_from_file'
          See https://docs.chef.io/deprecations_resource_cloning.html for further details.
         Cloning resource attributes for service[smb] from prior resource
       Previous service[smb]: /tmp/kitchen/cache/cookbooks/samba/resources/server.rb:83:in `block (3 levels) in class_from_file'
       Current  service[smb]: /tmp/kitchen/cache/cookbooks/samba/resources/server.rb:83:in `block (3 levels) in class_from_file' at 1 location:
           - /tmp/kitchen/cache/cookbooks/samba/resources/server.rb:83:in `block (3 levels) in class_from_file'
          See https://docs.chef.io/deprecations_resource_cloning.html for further details.
         Cloning resource attributes for service[nmb] from prior resource
       Previous service[nmb]: /tmp/kitchen/cache/cookbooks/samba/resources/server.rb:83:in `block (3 levels) in class_from_file'
       Current  service[nmb]: /tmp/kitchen/cache/cookbooks/samba/resources/server.rb:83:in `block (3 levels) in class_from_file' at 1 location:
           - /tmp/kitchen/cache/cookbooks/samba/resources/server.rb:83:in `block (3 levels) in class_from_file'
          See https://docs.chef.io/deprecations_resource_cloning.html for further details.

Both samba_server and samba_share are in the root context.
https://github.com/sous-chefs/samba/blob/master/resources/share.rb#L39
https://github.com/sous-chefs/samba/blob/master/resources/server.rb#L57

the test recipe runs as such
https://github.com/sous-chefs/samba/blob/master/test/fixtures/cookbooks/test/recipes/server.rb

from samba.

right so you're calling samba_server twice which is not using edit_resource, so you're getting two resources and resource cloning

from samba.

We're editing it twice rather than calling it twice, unless I'm going bonkers (which is entirely possible)

samba_server 'Samba Server' do
  interfaces 'lo 127.0.0.1 enp* eth*'
end

samba_share 'first_share' do
  comment 'exported share 1'
  path '/srv/export'
  guest_ok 'no'
  printable 'no'
  write_list ['test_user_1']
  create_mask '0644'
  directory_mask '0775'
end

samba_share 'second_share' do
  comment 'exported share 2'
  path '/srv/export_2'
  guest_ok 'no'
  printable 'no'
  write_list ['test_user_2']
  create_mask '0644'
  directory_mask '0775'
  create_directory false
end

from samba.

it also sounds like you've got a test fixture with a recipe in it which tries to directly create a template[/etc/samba/smb.conf] resource

it may be better to write a custom resource which does literally nothing other than wrap that template resource in the accumulator pattern:

action :create do
  with_run_context :root do
     edit_resource(:template, ...) do
        ...
        action :nothing
        delayed_action :create
      end
   end
end

the shitty thing is that there's no way to mixin the template interface, so you'll be stuck copying all the properties you care about from the template resource.

from samba.

lets see if this is clearer:

       Previous template[/etc/samba/smb.conf]: /tmp/kitchen/cache/cookbooks/samba/resources/server.rb:58:in `block (2 levels) in class_from_file'
       Current  template[/etc/samba/smb.conf]: /tmp/kitchen/cache/cookbooks/samba/resources/server.rb:58:in `block (2 levels) in class_from_file' at 1 location:

the problem here is that the message is a bit useless since its the same line in the same file, while the more interesting question is what code called both of those.

but what its saying is that you called samba_server twice somehow.

the way you've written your resource -- using a simple declaration -- you will get a new template resource created every time you call that samba_server resource, which is clearly what is happening.

you should probably use edit_resource to create the resource in samba_server so that it can be called multiple times.

from samba.

if you don't intend for it to be ever called twice you could raise "cannot call samba_server twice" if resources(template: "/etc/samba/smb.conf") before declaring the resource which would assert that samba_server was only called once and used the presence of the template resource as a flag to raise on when being called twice.

i seem to have missed that function in the find/edit/delete_resource API where the record must be created, and will fail if it already exists....

from samba.

Ah that's pretty cool

What I've been noticing is it's resetting the resource back to the default before writing out the properly compiled resource (samba_server+samba_share+samba_share)
e.g.

          # Declared in /tmp/kitchen/cache/cookbooks/test/recipes/server.rb:4:in `from_file'

           samba_server("Samba Server") do
             action [:create]
             retries 0
             retry_delay 2
             default_guard_interpreter :default
             declared_type :samba_server
             cookbook_name "test"
             recipe_name "server"
             server_string "Samba Server"
             workgroup "SAMBA"
             interfaces "lo 127.0.0.1" <<<<< this should actually be interfaces 'lo 127.0.0.1 enp* eth*'
             hosts_allow "127.0.0.0/8"
             security "user"
             passdb_backend "tdbsam"
             config_file "/etc/samba/smb.conf"
             map_to_guest "Bad User"
             load_printers "no"
             dns_proxy "no"
           end

from samba.

i'm sort of guessing but most likely what is happening there is that the first declaration creates a resource with the defaults, then the second declaration is the one that creates the second resource with the updated interfaces line.

basically you're creating two variables with the same name, and then scribbling over one or the other of them, but they're distinct objects, so you're getting weird results.

once you resolve the 3694 errors and get rid of the two resources and only have one, then either that magically fixes problems like this, or else it becomes clearer that there's other bugs.

from samba.

@josqu4red your example config is lacking a few things write_list is required

after that we're down to the actual error which seems to be (now I've got my test config actually correct...)

The smb.conf resource is evaluated on disk before the accumulator is finished

Processing samba_server[server] 
Processing yum_package[samba]
Processing template[/etc/samba/smb.conf]
  update content in file /etc/samba/smb.conf from 88a099 to e79d07
Processing service[smb] action enable
Processing service[smb] action start
Processing service[nmb] action enable
Processing service[nmb] action start
Processing samba_share[backup]
  Processing directory[/srv/backup]
Processing samba_share[torrents]
Processing directory[/srv/torrents]
Processing samba_share[media]
Processing directory[/srv/media]
Processing samba_user[test_user_1]
Processing linux_user[test_user_1]
Processing group[test_user_1]
Processing directory[/home/test_user_1]
 Processing execute[Create samba user test_user_1]
Processing template[/etc/samba/smb.conf] <-- ohai!?
Processing service[smb] action restart 
Processing service[nmb] action restart

from samba.

Thanks @damacus, @lamont-granquist for fixing this and for an interesting reading 👍

from samba.

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

from samba.