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:

[WebDNA] [WSC] WebDNA Development Summit (2014) Can this be done? (1997) Multiple security dbs (1997) WebCat2 beta 11 - new prefs ... (1997) apostrophe in search item (1997) Templates for Customer Database? (1997) what's wrong with this picture (2006) How about this? (1998) Not really WebCat (1997) Combining search criteria (2000) code below an [authenticate] gets evaluated? (2000) Help name our technology! I found it (1997) Catalogs and W* (1996) WebCatalog 2.0.1 for Windows released! (1997) Merchant account (1998) Verifying both name and password (was: New Problem) (1997) b12 cannot limit records returned and more. (1997) Pre-flight public flag (1997) Follow-Up to: Removing [showif] makes a big difference in speed (1997) possible, WebCat2.0 and checkboxes-restated (1997)