Bug #2629
closed
Rudder agent can not authenticate to webdav anymore
Added by François ARMAND over 12 years ago. Updated about 12 years ago.
Description
Since we change the password required for webdav connection, rudder agents can not connect anymore to the server to send inventory: they can't know what the password is.
I don't see any simple solution safe asking for the password on agent installation.
Updated by François ARMAND over 12 years ago
- Subject changed from Rudder agen can not authenticate to webdav to Rudder agent can not authenticate to webdav anymore
Updated by Jonathan CLARKE over 12 years ago
Oh wow, that's an aspect of this change we overlooked!!!
To clarify, what's happening here is this:- Random passwords are now automatically generated for all parts of Rudder server's components, including the password used to access the WebDAV share
- The WebDAV share is fed into rudder-web, and used to generate promises for nodes so that they can continue to send their inventory data
- BUT, for new nodes, they use initial promises and try to use the default password to connect, thus failing if the password has been changed on the server...
- Don't change the password and always use the default one (meh)
- Have two WebDAV shares, one for accepted and authenticated nodes, and one for new, unauthenticated nodes (well, authenticated but using a well-known default password) and handle them differently (sounds good, but the webapp doesn't make a difference currently)
- Have the server share some initial promises with the right WebDAV password in, and let new nodes go and fetch them
Any thoughts?
Updated by Matthieu CERDA over 12 years ago
- Status changed from New to Discussion
Well, the best approach I can figure out so far would be to ask for a webdav password during rudder-agent installation and set it in the installed initial promises. Else we have two choices: Find another way or revert the change :/ (but that would be sad)
Updated by Jonathan CLARKE over 12 years ago
- Assignee changed from Jonathan CLARKE to Matthieu CERDA
Matthieu CERDA wrote:
Well, the best approach I can figure out so far would be to ask for a webdav password during rudder-agent installation and set it in the installed initial promises. Else we have two choices: Find another way or revert the change :/ (but that would be sad)
Well, my previous comment already suggests two other ways. What do you think of them?
Updated by François ARMAND over 12 years ago
@Jon: well, I don't like very much 1/ and 3/.
1/ for obvious reason, even if I don't know how much dangerous this is compared to letting other password to default.
3/ means a second way to distribute policies, and this seems to be a BAD idea, because that means a hard coupling between two completlly not linked problematic. And so, when we will want to evolves one, we will have to take care of the two at once.
So I would go to 2/, and moreover it seems to be a good solution. Even if for starting, we just log more info for the unauthenticated part, save theses inventories (or other crap sent by malicious guys) in a special directory and clean it every hours (or even after every cf-agent run which processed inventories).
Updated by Nicolas CHARLES over 12 years ago
I don't see the point of 3 : if the server shares the password to everyone in the network, then it's not a secret for the nodes in the networks. Since the webdav only accepts posts from the networks, with the password, if the password is secret or not doesn't change much
1/ has the good advantages of ease.
2/ I like this idea, but would we have time to implement it for the beta ?
Updated by Matthieu CERDA over 12 years ago
Well, I would go for the second one.
Updated by Matthieu CERDA over 12 years ago
- Assignee changed from Matthieu CERDA to Jonathan CLARKE
Well, everybody is agreeing on the second approach I see. Time to prepare some specs !
Well, which name should we use for the directory containing the "unauthenticated" inventories ? Today we have inventories/incoming and inventories/received, I propose not to change the initial promises to still use the incoming directory, and add an inventories/auth-incoming directory for the authenticated inventories.
Updated by Jonathan CLARKE over 12 years ago
- Assignee changed from Jonathan CLARKE to Matthieu CERDA
Matthieu CERDA wrote:
Well, everybody is agreeing on the second approach I see. Time to prepare some specs !
Well, which name should we use for the directory containing the "unauthenticated" inventories ? Today we have inventories/incoming and inventories/received, I propose not to change the initial promises to still use the incoming directory, and add an inventories/auth-incoming directory for the authenticated inventories.
I'm not sure about the name 'auth-incoming', because although it is indeed a good description of how inventories arrive, it doesn't describe their real difference: some are from new, non-accepted nodes, and some are updates for existing nodes.
How about inventories/pending-nodes (for inventories from new nodes via initial promises) and inventories/accepted-nodes (for authenticated inventories) ?
Updated by Matthieu CERDA over 12 years ago
- Status changed from Discussion to In progress
Well, I was trying to do that to keep a compatibility with the original init policies, but all right. I'll do it right away !
Updated by Jonathan CLARKE over 12 years ago
Matthieu CERDA wrote:
Well, I was trying to do that to keep a compatibility with the original init policies, but all right. I'll do it right away !
Ah yes, that's a good idea. I hadn't realized.
I agree we should keep "incoming" for new nodes then, it will make migration easier. So we'd have "inventories/incoming" and "inventories/accepted-nodes-updates" ?
Updated by Matthieu CERDA over 12 years ago
- Status changed from In progress to Pending technical review
- % Done changed from 40 to 100
All done. Please express any concerns here.
Updated by Jonathan CLARKE over 12 years ago
- Target version changed from 50 to 2.4.0~beta3
Updated by Nicolas PERRON over 12 years ago
htpasswd-webdav-initial has been forgotten and corrected at the issue #2690
Updated by Nicolas PERRON over 12 years ago
I suppose this issue can be closed like #2690 was ?
Updated by Jonathan CLARKE about 12 years ago
- Status changed from Pending technical review to Released
This looks good, considering #2690.