Hi On Sat, 9 Feb 2002, Shachar Shemesh wrote:
> D. The/proc directory and subdirs has a "proc" gid, and a 550 > permissions on some of the directories. This means that users that are > not members of the "proc" group, cannot view other people's processes. > Doing "ps ax" from such a user returns only that user's processes. Same > goes for top, w, and any other /proc related utilitiy. All valid users > of the machine should add themselves to the proc group, which will bring > the situation back to normal. Could you please add 'tzafrir' to this group? I think that basically all shell users should be in this group, so they will be able to see the status of the system. Note that some services currently run with UIDs of users (e.g: I believe that MySQL runs as 'shlomif', but I probably can't check that now) > > I woke up this morning with an ambitious plan. I will add the OW patch > to the list of patches the SRPM has, and build from there. I will also > add a patch I'll prepare to bring MAX_LOOP to 32 (actually, I only > needed to change the RH patch that raised itfrom 8 to 16). I started to > work on that, when I realized I am going to run into all the conflicts, > all over again. Manually removing the patches I applied via OW was no > better than resolving the conflicts. At that stage I decided to forego > that option. Basically you should have either modified the patches, or add your own patches in the middle to resolve those conflicts. The general rule of thumb is that anything that you can do manually, you can also do in the RPM script. The problem with this approach is that any time you try a new patch you have to re-run the whole %prep phase, which means extracting the whole source tarball and applying all the patches. Another problem with rebuilding a source RPM is that this source RPM actually rebuilds to a number of binary kernel RPMs (i386, i586 and i686). -- Tzafrir Cohen mailto:[EMAIL PROTECTED] http://www.technion.ac.il/~tzafrir ---------------------------------------------------------------------------- To unsubscribe, send a message to [EMAIL PROTECTED] Archives available at http://www.mail-archive.com/[email protected]/
