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--679675921 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; 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. >=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--679675921 Content-Transfer-Encoding: quoted-printable Content-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:

    
  1. Re: [WebDNA] sudo and shell (Donovan Brooke 2010)
  2. Re: [WebDNA] sudo and shell (Thierry Almy 2010)
  3. Re: [WebDNA] sudo and shell (Donovan Brooke 2010)
  4. Re: [WebDNA] sudo and shell (Thierry Almy 2010)
  5. Re: [WebDNA] sudo and shell (Donovan Brooke 2010)
  6. Re: [WebDNA] sudo and shell (Thierry Almy 2010)
  7. Re: [WebDNA] sudo and shell (Thierry Almy 2010)
  8. Re: [WebDNA] sudo and shell (Thierry Almy 2010)
  9. Re: [WebDNA] sudo and shell (Bob Minor 2010)
  10. Re: [WebDNA] sudo and shell (Donovan Brooke 2010)
  11. [WebDNA] sudo and shell (Thierry Almy 2010)
--Apple-Mail-2--679675921 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; 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. >=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--679675921 Content-Transfer-Encoding: quoted-printable Content-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:

Individual LineItemChangePassword files would be better ... (1999) Mac Lockup Problems (1998) RE: [WebDNA] Convert Carriage Return From DB to Plain Text File (2019) autosensing lanague selection (1997) Doctype (2004) [listdatabases] feature request. (2003) .. more on sliding discounts... (1997) [WebDNA] Daily tasks without triggers (2011) problems with 2 tags (1997) [WebDNA] can webdna's [grep] find and replace ONLY the literal (2012) RE: Error -108 (1997) Writefile, Raw & include (2002) ups quickcost [repost] (1999) Problem (1997) WebCat2: multiple currency support (1997) UPS Calculator (2003) webten vs. webstar (1998) QuitFeedback & DBNotOpened errors (1997) Uploading very large image files (2003) RE: Suggestions for Topics to be covered in an Advanced WebDNACourse... (1998)