Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add check for registry entry in pkispawn #2832

Open
pki-bot opened this issue Oct 3, 2020 · 15 comments
Open

add check for registry entry in pkispawn #2832

pki-bot opened this issue Oct 3, 2020 · 15 comments
Milestone

Comments

@pki-bot
Copy link

pki-bot commented Oct 3, 2020

This issue was migrated from Pagure Issue #2712. Originally filed by vakwetu (@vakwetu) on 2017-05-26 11:15:33:


This resulted froma conversation with a community member who had run into this issue.

Specifically, the community member has attempted to run pkispawn again after an incomplete pkidestroy. The instance directory did not yet exist, but the registry entry under /etc/sysconfig/pki did.

As a result, when trying to create the master dictionary, we call :

compose_pki_master_dictionary , which calls instance.load(), which amongst other things, checks to see if the registry entry exists, and if so, tries to load the CS.cfg for that instance.

Of course at that point, the CS.cfg does not exist yet, and the installer bombs.

File "/usr/sbin/pkispawn", line 820, in
main(sys.argv)
File "/usr/sbin/pkispawn", line 502, in main
create_master_dictionary(parser)
File "/usr/sbin/pkispawn", line 644, in create_master_dictionary
parser.compose_pki_master_dictionary()
File "/usr/lib/python2.7/dist-packages/pki/server/deployment/pkiparser.py", line 615, in compose_pki_master_dictionary
instance.load()
File "/usr/lib/python2.7/dist-packages/pki/server/init.py", line 595, in load
subsystem.load()
File "/usr/lib/python2.7/dist-packages/pki/server/init.py", line 129, in load
lines = open(self.cs_conf).read().splitlines()
IOError: [Errno 2] No such file or directory: '/var/lib/pki/pki-tomcat/ca/conf/CS.cfg'

This is somewhat confusing. One way to fix this would be to check for the registry entry before all this happens. We do check for the existence of the top level instance directory beforehand in the main() function in pkispawn. We could add a check for the registry entry too.

Another would be to refactor the load() function to not read the CS.cfg in this case.

@pki-bot pki-bot added this to the 10.5 milestone Oct 3, 2020
@pki-bot
Copy link
Author

pki-bot commented Oct 3, 2020

Comment from vakwetu (@vakwetu) at 2017-05-26 11:18:11

Just as a note, I suspect folks have run into this before, which is why we get bug reports like this:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844119, where the proposed solution is absolutely wrong!

@pki-bot
Copy link
Author

pki-bot commented Oct 3, 2020

Comment from vakwetu (@vakwetu) at 2017-05-26 11:18:15

Metadata Update from @vakwetu:

  • Custom field component adjusted to General
  • Custom field feature adjusted to ''
  • Custom field origin adjusted to Community
  • Custom field proposedmilestone adjusted to ''
  • Custom field proposedpriority adjusted to ''
  • Custom field reviewer adjusted to ''
  • Custom field type adjusted to defect
  • Custom field version adjusted to ''

@pki-bot
Copy link
Author

pki-bot commented Oct 3, 2020

Comment from mharmsen (@mharmsen) at 2017-05-26 14:02:20

Metadata Update from @mharmsen:

  • Issue assigned to vakwetu
  • Issue priority set to: critical
  • Issue set to the milestone: 10.4

@pki-bot
Copy link
Author

pki-bot commented Oct 3, 2020

Comment from mharmsen (@mharmsen) at 2017-05-26 14:04:12

Metadata Update from @mharmsen:

  • Issue priority set to: None (was: critical)
  • Issue set to the milestone: 0.0 NEEDS_TRIAGE (was: 10.4)

@pki-bot
Copy link
Author

pki-bot commented Oct 3, 2020

Comment from mharmsen (@mharmsen) at 2017-06-01 14:47:57

Metadata Update from @mharmsen:

  • Issue priority set to: critical
  • Issue set to the milestone: 10.4 (was: 0.0 NEEDS_TRIAGE)

@pki-bot
Copy link
Author

pki-bot commented Oct 3, 2020

Comment from mharmsen (@mharmsen) at 2017-06-01 14:48:22

Metadata Update from @mharmsen:

@pki-bot
Copy link
Author

pki-bot commented Oct 3, 2020

Comment from mharmsen (@mharmsen) at 2017-06-02 16:37:18

After discussions with vakwetu and edewata, moving to 10.5.

@pki-bot
Copy link
Author

pki-bot commented Oct 3, 2020

Comment from mharmsen (@mharmsen) at 2017-06-02 16:37:19

Metadata Update from @mharmsen:

  • Issue set to the milestone: 10.5 (was: 10.4)

@pki-bot
Copy link
Author

pki-bot commented Oct 3, 2020

Comment from vakwetu (@vakwetu) at 2017-06-02 16:39:24

The solution isn't as simple as adding a check to pkispawn before the master dictionary is composed. There are cases where the registry and instance should exist beforehand -- like an extrenal CA signing the keys or step 2 of a 2-step install.

Maybe a better fix for this is by creating a pki-nuke script.

@pki-bot
Copy link
Author

pki-bot commented Oct 3, 2020

Comment from mharmsen (@mharmsen) at 2017-08-31 00:27:05

Metadata Update from @mharmsen:

  • Issue priority set to: major (was: critical)

@pki-bot
Copy link
Author

pki-bot commented Oct 3, 2020

Comment from mharmsen (@mharmsen) at 2017-10-25 13:58:57

[20171025] - Offline Triage ==> 10.6

@pki-bot
Copy link
Author

pki-bot commented Oct 3, 2020

Comment from mharmsen (@mharmsen) at 2017-10-25 13:58:58

Metadata Update from @mharmsen:

  • Issue set to the milestone: 10.6 (was: 10.5)

@pki-bot
Copy link
Author

pki-bot commented Oct 3, 2020

Comment from mharmsen (@mharmsen) at 2018-04-23 21:11:26

Per 10.5.x/10.6 Triage: 10.5.x

alee: we've seen this in cases of incomplete install/renewal. fixing this will help in failed installs/cleanups.

@pki-bot
Copy link
Author

pki-bot commented Oct 3, 2020

Comment from mharmsen (@mharmsen) at 2018-04-23 21:11:26

Metadata Update from @mharmsen:

  • Issue set to the milestone: 10.5 (was: 10.6)

@pki-bot
Copy link
Author

pki-bot commented Oct 3, 2020

Comment from dmoluguw (@SilleBille) at 2018-11-09 11:01:46

we have a solution that doesn't directly fix this ticket: pkidestroy --force which force removes remnant files of an incomplete installation.

Related Upstream ticket: https://pagure.io/dogtagpki/issue/1172
Related PR [10.5]: #93

This new feature is available in master branch as well.

Can this ticket be considered to be closed?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant