{"id":789,"date":"2010-01-28T22:03:37","date_gmt":"2010-01-29T03:03:37","guid":{"rendered":"http:\/\/blogs.law.harvard.edu\/hoanga\/?p=789"},"modified":"2010-01-28T22:03:37","modified_gmt":"2010-01-29T03:03:37","slug":"debugging-when-puppetd-gives-read_cert-super-no-superclass-method-read_cert-nomethoderror","status":"publish","type":"post","link":"https:\/\/archive.blogs.harvard.edu\/hoanga\/2010\/01\/28\/debugging-when-puppetd-gives-read_cert-super-no-superclass-method-read_cert-nomethoderror\/","title":{"rendered":"Debugging when puppetd gives `read_cert’: super: no superclass method `read_cert’ (NoMethodError)"},"content":{"rendered":"

I just ran into this obscure problem with Puppet. I’m writing it down in the hopes I will remember not to do something like this again…<\/p>\n

\n
\r\n$ sudo puppetd --test --noop\r\n\/opt\/local\/lib\/ruby\/site_ruby\/1.8\/puppet\/network\/http_pool.rb:41:in `read_cert': super: no superclass method `read_cert' (NoMethodError)\r\n \u00a0 \u00a0 \u00a0 \u00a0from \/opt\/local\/lib\/ruby\/site_ruby\/1.8\/puppet\/executables\/client\/certhandler.rb:62:in `read_cert'\r\n \u00a0 \u00a0 \u00a0 \u00a0from \/opt\/local\/lib\/ruby\/site_ruby\/1.8\/puppet\/executables\/client\/certhandler.rb:24:in `read_retrieve'\r\n \u00a0 \u00a0 \u00a0 \u00a0from \/opt\/local\/bin\/puppetd:347\r\n<\/pre>\n<\/blockquote>\n
THE FIX<\/h3>\n
This error is caused by  old puppet binaries that were installed from source that were not removed with subsequent upgrades of puppet itself.  The newer versions I am installing install via packages which always installs puppetd into \/opt\/local\/sbin.<\/p>\n
To fix this, delete the old puppet binaries from wherever they were installed.  In my case it is \/opt\/local\/bin<\/p>\n
\n
\r\n# Hope there aren't any useful binaries named pu* that are not puppet-based\r\n$ rm \/opt\/local\/bin\/pu*\r\n<\/pre>\n<\/blockquote>\n
Now we have a working puppet run!<\/p>\n
\n
\r\n$ sudo  puppetd --no-daemonize --verbose --debug --onetime --test\r\ndebug: Failed to load library 'selinux' for feature 'selinux'\r\ndebug: Failed to load library 'shadow' for feature 'libshadow'\r\ndebug: Puppet::Type::User::ProviderNetinfo: file nireport does not exist\r\ndebug: Puppet::Type::User::ProviderLdap: true value when expecting false\r\ndebug: Puppet::Type::User::ProviderPw: file pw does not exist\r\ndebug: Puppet::Type::User::ProviderDirectoryservice: file \/usr\/bin\/dscl does not exist\r\ndebug: Failed to load library 'ldap' for feature 'ldap'\r\ndebug: \/File[\/var\/puppet\/state]: Autorequiring File[\/var\/puppet]\r\ndebug: \/File[\/etc\/puppet\/ssl\/private_keys]: Autorequiring File[\/etc\/puppet\/ssl]\r\ndebug: \/File[\/etc\/puppet\/ssl\/certs]: Autorequiring File[\/etc\/puppet\/ssl]\r\ndebug: \/File[\/etc\/puppet\/ssl\/certificate_requests]: Autorequiring File[\/etc\/puppet\/ssl]\r\ndebug: \/File[\/var\/puppet\/clientbucket]: Autorequiring File[\/var\/puppet]\r\ndebug: \/File[\/etc\/puppet\/ssl]: Autorequiring File[\/etc\/puppet]\r\ndebug: \/File[\/etc\/puppet\/ssl\/public_keys]: Autorequiring File[\/etc\/puppet\/ssl]\r\ndebug: \/File[\/var\/puppet\/lib]: Autorequiring File[\/var\/puppet]\r\ndebug: \/File[\/etc\/puppet\/ssl\/private]: Autorequiring File[\/etc\/puppet\/ssl]\r\ndebug: \/File[\/var\/puppet\/client_yaml]: Autorequiring File[\/var\/puppet]\r\ndebug: \/File[\/var\/puppet\/log]: Autorequiring File[\/var\/puppet]\r\ndebug: \/File[\/var\/puppet\/facts]: Autorequiring File[\/var\/puppet]\r\ndebug: \/File[\/var\/puppet\/run]: Autorequiring File[\/var\/puppet]\r\ndebug: \/File[\/var\/puppet\/state\/graphs]: Autorequiring File[\/var\/puppet\/state]\r\ndebug: Finishing transaction 80433160 with 0 changes\r\n<\/pre>\n<\/blockquote>\n","protected":false},"excerpt":{"rendered":"
I just ran into this obscure problem with Puppet. I’m writing it down in the hopes I will remember not to do something like this again… $ sudo puppetd –test –noop \/opt\/local\/lib\/ruby\/site_ruby\/1.8\/puppet\/network\/http_pool.rb:41:in `read_cert’: super: no superclass method `read_cert’ (NoMethodError) \u00a0 \u00a0 \u00a0 \u00a0from \/opt\/local\/lib\/ruby\/site_ruby\/1.8\/puppet\/executables\/client\/certhandler.rb:62:in `read_cert’ \u00a0 \u00a0 \u00a0 \u00a0from \/opt\/local\/lib\/ruby\/site_ruby\/1.8\/puppet\/executables\/client\/certhandler.rb:24:in `read_retrieve’ \u00a0 \u00a0 \u00a0 \u00a0from […]<\/p>\n","protected":false},"author":703,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1216,14625,4115],"tags":[14626],"class_list":["post-789","post","type-post","status-publish","format-standard","hentry","category-fixes","category-puppet","category-sysadmin","tag-puppet"],"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/archive.blogs.harvard.edu\/hoanga\/wp-json\/wp\/v2\/posts\/789","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/archive.blogs.harvard.edu\/hoanga\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/archive.blogs.harvard.edu\/hoanga\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/archive.blogs.harvard.edu\/hoanga\/wp-json\/wp\/v2\/users\/703"}],"replies":[{"embeddable":true,"href":"https:\/\/archive.blogs.harvard.edu\/hoanga\/wp-json\/wp\/v2\/comments?post=789"}],"version-history":[{"count":7,"href":"https:\/\/archive.blogs.harvard.edu\/hoanga\/wp-json\/wp\/v2\/posts\/789\/revisions"}],"predecessor-version":[{"id":796,"href":"https:\/\/archive.blogs.harvard.edu\/hoanga\/wp-json\/wp\/v2\/posts\/789\/revisions\/796"}],"wp:attachment":[{"href":"https:\/\/archive.blogs.harvard.edu\/hoanga\/wp-json\/wp\/v2\/media?parent=789"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/archive.blogs.harvard.edu\/hoanga\/wp-json\/wp\/v2\/categories?post=789"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/archive.blogs.harvard.edu\/hoanga\/wp-json\/wp\/v2\/tags?post=789"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}