Re: [WebDNA] sudo and shell
This WebDNA talk-list message is from 2010
It keeps the original formatting.
numero = 105172
interpreted = N
texte = --Apple-Mail-2--679675921Content-Transfer-Encoding: quoted-printableContent-Type: text/plain;charset=us-asciiI gave it another try.The folder to delete is:=/Library/PodcastProducer/Shared/Content/2010-03-31/3B74EFFD-27D6-4F5F-9460=-1DA5D360C7B5.prbI set permissions for the folder "2010-03-31" to 777 recursively.Then I restarted WebDNA (just in case)The command is:[shell]/bin/rm -rf =/Library/PodcastProducer/Shared/Content/2010-03-31/3B74EFFD-27D6-4F5F-9460=-1DA5D360C7B5.prb[/shell]But the folder wont get deleted ....I searched for log entries for this event but didn't find any.Any ideas what I could try?Thierry> Thierry Almy wrote:> [snip]>> this looks quite tricky ... more difficult that I have thought ...>> I changed the ownership of the Content Folder to 777 -R, but it =didn't help, guess I'd have to change the folders above as well ...>> I don't want to mess up permissions in the PodcastProducer Library, =it's quite a delicately system and I don't want to break it! so I went =back to 775.>=20>=20> You won't have to change perms a level above the 'Content' folder, but =you will have to change the actual file that you want to delete. Both> the content and the file to delete must be writable by WebDNA's user> or group.>=20> Also, it shouldn't hurt the PodcastProducer setup in going the =direction> of "more accessible" regarding permissions. 777 should be fine.. at =least for testing.>=20>=20>> If the rm -rf isn't possible, I'm thinking about writing the folder =paths to be deleted in a database. Then retrieve them all together =formatted as a shell script which can be copy/pasted in to the terminal =then enter the password manually.>> It's not the solution that I have dreamed of but better than nothing =...>=20>=20> Sure, access to the non Web portions of a server via an appropriate =SSH session is likely more recommended. There is a reason why you run =your web environment as a different user:group than> the rest of the server. ;-)>=20>=20> Donovan>=20--Apple-Mail-2--679675921Content-Transfer-Encoding: quoted-printableContent-Type: text/html;charset=us-ascii
I gave it another try.
The folder to =delete =is:
/Library/PodcastProducer/Shared/Content/2010-03-31/3B74EFFD-=27D6-4F5F-9460-1DA5D360C7B5.prb
I set =permissions for the folder "2010-03-31" to 777 =recursively.
Then I restarted WebDNA (just in =case)
The command is:
[shell]/bin/rm =-rf =/Library/PodcastProducer/Shared/Content/2010-03-31/3B74EFFD-27D6-4F5F-9460=-1DA5D360C7B5.prb[/shell]
But =the folder wont get deleted ....
I searched for =log entries for this event but didn't find =any.
Any ideas what I could =try?
Thierry
Thierry Almy wrote:
[snip]
this looks quite tricky ... more difficult that I have =thought ...
I changed the =ownership of the Content Folder to 777 -R, but it didn't help, guess I'd =have to change the folders above as well ...
I don't want to mess up permissions in the PodcastProducer =Library, it's quite a delicately system and I don't want to break it! so =I went back to 775.
You won't have to change =perms a level above the 'Content' folder, but you will have to change =the actual file that you want to delete. Both
the content and the =file to delete must be writable by WebDNA's user
or =group.
Also, it shouldn't hurt the PodcastProducer setup in going =the direction
of "more accessible" regarding permissions. 777 should =be fine.. at least for testing.
If =the rm -rf isn't possible, I'm thinking about writing the folder paths =to be deleted in a database. Then retrieve them all together formatted =as a shell script which can be copy/pasted in to the terminal then enter =the password manually.
It's =not the solution that I have dreamed of but better than nothing =...
Sure, access to the non Web portions of a =server via an appropriate SSH session is likely more recommended. There =is a reason why you run your web environment as a different user:group =than
the rest of the server. ;-)
Donovan
==--Apple-Mail-2--679675921--
Associated Messages, from the most recent to the oldest:
--Apple-Mail-2--679675921Content-Transfer-Encoding: quoted-printableContent-Type: text/plain;charset=us-asciiI gave it another try.The folder to delete is:=/Library/PodcastProducer/Shared/Content/2010-03-31/3B74EFFD-27D6-4F5F-9460=-1DA5D360C7B5.prbI set permissions for the folder "2010-03-31" to 777 recursively.Then I restarted WebDNA (just in case)The command is:
[shell]/bin/rm -rf =/Library/PodcastProducer/Shared/Content/2010-03-31/3B74EFFD-27D6-4F5F-9460=-1DA5D360C7B5.prb[/shell]But the folder wont get deleted ....I searched for log entries for this event but didn't find any.Any ideas what I could try?Thierry> Thierry Almy wrote:> [snip]>> this looks quite tricky ... more difficult that I have thought ...>> I changed the ownership of the Content Folder to 777 -R, but it =didn't help, guess I'd have to change the folders above as well ...>> I don't want to mess up permissions in the PodcastProducer Library, =it's quite a delicately system and I don't want to break it! so I went =back to 775.>=20>=20> You won't have to change perms a level above the 'Content' folder, but =you will have to change the actual file that you want to delete. Both> the content and the file to delete must be writable by WebDNA's user> or group.>=20> Also, it shouldn't hurt the PodcastProducer setup in going the =direction> of "more accessible" regarding permissions. 777 should be fine.. at =least for testing.>=20>=20>> If the rm -rf isn't possible, I'm thinking about writing the folder =paths to be deleted in a database. Then retrieve them all together =formatted as a shell script which can be copy/pasted in to the terminal =then enter the password manually.>> It's not the solution that I have dreamed of but better than nothing =...>=20>=20> Sure, access to the non Web portions of a server via an appropriate =SSH session is likely more recommended. There is a reason why you run =your web environment as a different user:group than> the rest of the server. ;-)>=20>=20> Donovan>=20--Apple-Mail-2--679675921Content-Transfer-Encoding: quoted-printableContent-Type: text/html;charset=us-ascii
I gave it another try.
The folder to =delete =is:
/Library/PodcastProducer/Shared/Content/2010-03-31/3B74EFFD-=27D6-4F5F-9460-1DA5D360C7B5.prb
I set =permissions for the folder "2010-03-31" to 777 =recursively.
Then I restarted WebDNA (just in =case)
The command is:
[shell]/bin/rm =-rf =/Library/PodcastProducer/Shared/Content/2010-03-31/3B74EFFD-27D6-4F5F-9460=-1DA5D360C7B5.prb[/shell]
But =the folder wont get deleted ....
I searched for =log entries for this event but didn't find =any.
Any ideas what I could =try?
Thierry
Thierry Almy wrote:
[snip]
this looks quite tricky ... more difficult that I have =thought ...
I changed the =ownership of the Content Folder to 777 -R, but it didn't help, guess I'd =have to change the folders above as well ...
I don't want to mess up permissions in the PodcastProducer =Library, it's quite a delicately system and I don't want to break it! so =I went back to 775.
You won't have to change =perms a level above the 'Content' folder, but you will have to change =the actual file that you want to delete. Both
the content and the =file to delete must be writable by WebDNA's user
or =group.
Also, it shouldn't hurt the PodcastProducer setup in going =the direction
of "more accessible" regarding permissions. 777 should =be fine.. at least for testing.
If =the rm -rf isn't possible, I'm thinking about writing the folder paths =to be deleted in a database. Then retrieve them all together formatted =as a shell script which can be copy/pasted in to the terminal then enter =the password manually.
It's =not the solution that I have dreamed of but better than nothing =...
Sure, access to the non Web portions of a =server via an appropriate SSH session is likely more recommended. There =is a reason why you run your web environment as a different user:group =than
the rest of the server. ;-)
Donovan
==--Apple-Mail-2--679675921--
Thierry Almy
DOWNLOAD WEBDNA NOW!
Top Articles:
Talk List
The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...
Related Readings:
Updating a database once per day - An example (1998)
[switch][case] (2004)
updating with ProductEditor (1998)
webcat- multiple selection in input field (1997)
multiple search commands (1997)
Re1000001: Setting up shop (1997)
WebCatalog can't find database (1997)
WebCat2b15MacPlugin - showing [math] (1997)
(OT) SERVER FREEZES ALL AT SAME TIME (2004)
Max Record length restated as maybe bug (1997)
FileInfo (2004)
Text limits in NT version? (1997)
[referrer] tag (1997)
Fwd: Problems with Webcatalog Plug-in (1997)
European Convention (2004)
expired beta (1997)
Days to Date Woes (2004)
how do I delete 1 of 2 identical records? (2003)
PR: WebCatalog Affiliates Program Announced -- Share the revenue for promoting WebCatalog (2000)
Emailer (1997)