This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
scp to nb.org fails when paramter -v (verbose) is used. Here is an example: % scp -rqv 5_0 upload@cvs.netbeans.org: Executing: program /usr/bin/ssh host cvs.netbeans.org, user upload, command scp -v -r -t . 'scp -v -r -t .' -- You are not authorized to do that. Our build tools use "scp -rqv" when do automated upload of NB build to nb.org. It means we are not able currently to upload any NB build to nb.org and nobody from developers can reach them.
Robert, is -v critical ? Can you (temporarily or not) remove it from the scripts ?
-v is not critical, but it would be high impact change - it would require several days to implement. This parameter is used for *all* automated uploads. The main reason is better failures tracking.
Interestingly -v is not the issue; try scp -v file_name upload@cvs.netbeans.org:.; I was able to do it. Even -t and -r is not an issue in itself. However, when I use all 3 (-rqv) this tells me that I am not aiuthorized. I will find out if this can be easily resolved.
I am going to make it a P2. This particular option should have been tested on stage if this was thought that critical for the upload.
Updating status whiteboard. Regards, Karthik Support Operations
Folks, we don't have new daily builds on netbeans.org due to this issue for several days already. Please, fix immediately.
This is as much our problem as Collab's - this should have been tested before the upgrade. Robert, considering this is a P1, can you pls consider starting work on removing -v from the scripts ? Collab, any updates ?
I would really appreciate if we don't have to remove this option from the build tools, because: - it means huge amount of work - all supported codelines are affected (3-4 days) as well as Update Center management (1-2 days) - our ability to debug upload problem would decrease I agree, this could be cought during testig, but this is very basic option that we wouldn't expect stop working. Isn't it just a configuration issue ? Furthermore, what was the reason to disable -v (verbose) option ? Actually, as I found out later the problem appears whne of options is used, for example: -vr or -qv
Hi, We are working on this issue right now. Sooner we will be back with a fix. Thanks, Kavitha Support operations
Hi, We have found out the root cause for the issue and currently are working on the fix, which as per the engineers would take some time since it has to be tested in the stage site before implementing on the production site. We will update you as soon as the fix is ready. Regards, Jeeva Support Operations
All, CN engineering has proposed a fix to this issue. However this will need to be reviewed by the Production Operations to make sure that there are no security concerns with these changes in place; and a QA of this on the stage has to happen. We are trying to move this as quickly as possible. FWIW: this problem is not explicitly with the -v flag, but with the -r flag; that too when a specific set of options are used. But I don't want to update the Summary right now. Thanks
*** Issue 77617 has been marked as a duplicate of this issue. ***
Ping ... any update ? This is a P1.
Getting a lot of dups/queries about this, updating summary to help ppl find it (searching on "daily").
Hi, As mentioned by ani in the earlier comment, the proposed fix is with the engineers and it seems to take a bit more time than expected since, 1. The code is under review to make sure it produces *only* the intended effects. 2. To make sure there is no regression. 3. To make sure that the security factor is covered. We will keep you updated as soon as it is tested successfully on the stage. Regards, Jeeva Support Operations
Further clarification: A few iterations of the scp-shell had been already reviewed by engineering and production operations. We should expect to get an updated version for testing on stage, today.
We rolled out the changed version on the stage site (stage.netbeans.org). We urgently need someone to verify this on the stage site. That way we can roll out the fix on the production server.
Clarification to my previous post. The changed version of "scp" is now available on the stage site for review. The fix will be scheduled for inclusion in a patch for the production server, due soon.
Ani, I've successfully uploaded using command scp -rpqv 200606121800 upload@stage.netbeans.org:. The thing which is bit scaring is that I was able to clean up after myself by using command ssh upload@stage.netbeans.org rm -r 200606121800 I was told that I should use 'rm -R' for recursive directory removals, but 'rm -r' worked just fine. Technically I don't object as I didn't automated bits removal, but this is difference from what I was told and may indicate another issue. Jack, would you please complete all other scp/ssh tests from your list?
Thanks Rudo for your help. My tests are probably a subset of what you've already tested, but I did them all anyway, including "-v" to make things interesting. Everything looks good (except the extra "data/" in the directory mapping on the stage site, but I assume that is unrelated to the ssh shell we are testing). I can't coment on the significance of -r working, just that -R still works as expected. Looks like a GO from our side; Collab, when can we schedule this patch to be applied ? Will it require downtime ?
Jack, We will discuss this in the conference call to-day.
Jack, Rudolph, Please let us know how concerning it is to allow the "-r" option. Since the users must have a valid "ssh" key to run this, is it really something that should worry you? What's the risk if someone actually runs an "rm -r" option (other than the effort to upload these once more)?
Ani, I'm sorry if I was not clear. I don't object. I just pointed out difference between expected behavior and real behavior. I'm fine with actual behavior having both options available (-r and -R). I guess we could agree on that 'rm -r' may stop working sometime in future and that the staged version gets GO for roll-out to production site.
Ani, we only mentioned it bcs *Collab* previously restricted use of "-r", and asked us to instead use "-R". It is no problem for us if they both work.
Fixed on production box (netbeans.org); can u please verify?
Verified. I noticed strangely that the accepted format of the target changed slightly : scp junk.txt upload@cvs.netbeans.org:./misc/ 'scp -t ./misc/' -- You are not authorized to do that. Removing "./" works : scp junk.txt upload@cvs.netbeans.org:misc/ junk.txt 100% 0 0.0KB/s --:-- ETA This is simple to workaround, so no big deal. Just interesting to note.
Fixed.
Based on Jack's comments, marking this issue as verified
We recently moved out from Collabnet's infrastructure