Jira (PUP-2931) Puppet CA sometimes resets certificate serial counter

3 views
Skip to first unread message

Adrien Thebo (JIRA)

unread,
Oct 17, 2016, 1:35:03 PM10/17/16
to puppe...@googlegroups.com
Adrien Thebo updated an issue
 
Puppet / Bug PUP-2931
Puppet CA sometimes resets certificate serial counter
Change By: Adrien Thebo
Labels: ca
Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe)
Atlassian logo

Russell Mull (JIRA)

unread,
May 15, 2017, 7:39:03 PM5/15/17
to puppe...@googlegroups.com

Josh Cooper (JIRA)

unread,
May 15, 2017, 11:15:02 PM5/15/17
to puppe...@googlegroups.com
Josh Cooper assigned an issue to Unassigned
Change By: Josh Cooper
Assignee: Andrew Parker

Moses Mendoza (JIRA)

unread,
May 18, 2017, 1:54:55 PM5/18/17
to puppe...@googlegroups.com

Elijah Lynn (JIRA)

unread,
Jun 20, 2018, 6:20:04 PM6/20/18
to puppe...@googlegroups.com
Elijah Lynn commented on Bug PUP-2931
 
Re: Puppet CA sometimes resets certificate serial counter

Providing more context around comment #1, https://www.rubydoc.info/gems/puppet/Puppet%2FFileSystem%2FFileImpl:exclusive_open

  1. File 'lib/puppet/file_system/file_impl.rb', line 51def exclusive_open(path, mode, options = 'r', timeout = 300, &block)wait = 0.001 + (Kernel.rand / 1000)written = falsewhile !written::File.open(path, options, mode) do |rf|if rf.flock(::File::LOCK_EX|::File::LOCK_NB)yield rfwritten = trueelsesleep waittimeout -= waitwait *= 2if timeout < 0raise Timeout::Error, _("Timeout waiting for exclusive lock on %{path}") % { path: @path }

    endendendendend

This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
Atlassian logo

Elijah Lynn (JIRA)

unread,
Jun 20, 2018, 6:33:03 PM6/20/18
to puppe...@googlegroups.com
Elijah Lynn commented on Bug PUP-2931

https://linux.die.net/man/2/flock

flock() does not lock files over NFS. Use fcntl(2) instead: that does work over NFS, given a sufficiently recent version of Linux and a server which supports locking.

Since kernel 2.0, flock() is implemented as a system call in its own right rather than being emulated in the GNU C library as a call to fcntl(2). This yields true BSD semantics: there is no interaction between the types of lock placed by flock() and fcntl(2), and flock() does not detect deadlock.

Elijah Lynn (JIRA)

unread,
Jun 20, 2018, 6:59:03 PM6/20/18
to puppe...@googlegroups.com
Elijah Lynn commented on Bug PUP-2931

Hrm, latest version of man flock here, http://man7.org/linux/man-pages/man2/flock.2.html, says:

 

NFS details In Linux kernels up to 2.6.11, flock() does not lock files over NFS (i.e., the scope of locks was limited to the local system). Instead, one could use fcntl(2) byte-range locking, which does work over NFS, given a sufficiently recent version of Linux and a server which supports locking. Since Linux 2.6.12, NFS clients support flock() locks by emulating them as fcntl(2) byte-range locks on the entire file. This means that fcntl(2) and flock() locks do interact with one another over NFS. It also means that in order to place an exclusive lock, the file must be opened for writing. Since Linux 2.6.37, the kernel supports a compatibility mode that allows flock() locks (and also fcntl(2) byte region locks) to be treated as local; see the discussion of the local_lock option in nfs(5).

And D10 here http://nfs.sourceforge.net/ says similar:

D10. I'm trying to use flock()/BSD locks to lock files used on multiple clients, but the files become corrupted. How come?A. flock()/BSD locks act only locally on Linux NFS clients prior to 2.6.12. Use fcntl()/POSIX locks to ensure that file locks are visible to other clients.Here are some ways to serialize access to an NFS file.Use the fcntl()/POSIX locking API. This type of locking provides byte-range locking across multiple clients via the NLM protocol, or via NFSv4.Use a separate lockfile, and create hard links to it. See the description in the O_EXCL section of the creat(2) man page.It's worth noting that until early 2.6 kernels, O_EXCL creates were not atomic on Linux NFS clients. Don't use O_EXCL creates and expect atomic behavior among multiple NFS client unless you are running a kernel newer than 2.6.5.It's a known issue that Perl uses flock()/BSD locking by default. This can break programs ported from other operating systems, such as Solaris, that expect flock/BSD locks to work like POSIX locks.On Linux, using file locking instead of a hard link has the added benefit of checkpointing the client's cache with the server. When a file lock is acquired, the client will flush the page cache for that file so that any subsequent reads get new data from the server. When a file lock is released, any changes to the file on that client are flushed back to the server before the lock is released so that other clients waiting to lock that file can see the changes.The NFS client in 2.6.12 provides support for flock()/BSD locks on NFS files by emulating the BSD-style locks in terms of POSIX byte range locks. Other NFS clients that use the same emulation mechanism, or that use fcntl()/POSIX locks, will then see the same locks that the Linux NFS client sees.On local Linux filesystems, POSIX locks and BSD locks are invisible to one another. Thus, due to this emulation, applications running on a Linux NFS server will still see files locked by NFS clients as being locked with a fcntl()/POSIX lock, whether the application on the client is using a BSD-style or a POSIX-style lock. If the server application uses flock()BSD locks, it will not see the locks the NFS clients use.

 

Josh Cooper (Jira)

unread,
Jan 27, 2021, 1:39:03 AM1/27/21
to puppe...@googlegroups.com
Josh Cooper commented on Bug PUP-2931

All of the CA functionality has been removed from puppet and now resides in puppetserver. There have been a number of improvements to the latter to protect CA related files from concurrent updates. Could you try to reproduce with puppetserver, and file a SERVER ticket? In the meantime, I'm going to close this issue.

This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935)
Atlassian logo
Reply all
Reply to author
Forward
0 new messages