pmpatrick

jboy, you are right. Shell scripts will not run suid in linux. Apparently, this has been the case for many years. Sorry for the confusion. Here's a nice article discussing the security dangers of suid scripts: http://www.samag.com/documents/s=1149/sam0106a/0106a.htm The main options in linux that replace suid shell scripts are sudo, creating a wrapper program in C to execute the script or create a perl script which can run suid. Sudo seems like the easiest approach.

Here's a pretty easy way that should accomplish what you originally wanted. First change the owner of the script file to root: # chown root <script name> Then change the permission on the script file to suid with execute permissions for all users: # chmod 4755 <script name> Under normal circumstances, a process like a script will launch with the permissions of the user that launched the script, regardless of the actual owner of the script, assuming the user has execute permission on the script. With suid, the script will launch with the permissions of the owner of the script, here root, regardless of which user actually launched the script. SUID is considered dangerous and insecure and should be used with caution. Here, you will give all users execute permissions on the script but when they launch that script it will run with root powers, i.e. the permissions of the owner. Sudo does pretty much the same thing but gives you much finer grade control over who can launch the script with root privileges.

Just to elaborate a bit, the file you need to edit is "nsFilePicker.js" which is located in the "components" subdirectory. I installed the updated firefox in my home directory using the linux package on the firefox website so mine is located at ~/firefox/components. It's pretty easy to find nsFilePicker.js just by locating your firefox "components" subdirectory. nsFilePicker.js is a pretty large and confusing file. Open it with kwrite and hit F11 to show the line numbers. In my version of firefox(1.5.0.5), the place where you need to make the edit begins at line 268, YMMV. You probably want to back up your original nsFilePicker.js somewhere so you can recover if you screw up the edit. One other tip - to make the edit take effect be sure to follow this direction in the article: I forgot to do that and couldn't get it to work. After I uninstalled and reinstalled adblock, it worked fine.

Came across this great article the other day in the gentoo wiki on how to integrate firefox with kde: http://gentoo-wiki.com/HOWTO_Integrate_Firefox_with_KDE For all you kde users that are sick and tired of the gnome file save window that pops up in firefox everytime you want to download a file, the above article describes in detail how to change that so you get your usuall kde file save window. In addition, there are several other tips on integrating firefox with kde included in this excellent article. A must read for any kde user. moved to tips and tricks by ianw1974 (felt this the best place for it)

Alternatively: $ lspci

Try resetting your JAVA_HOME in your ~/.bash_profile. That should work; the home .bash_profile overrides the global settings in /etc/profile and probably whatever else is resetting your JAVA_HOME as that appears to be what is occurring.

If you are running mdv 2006, I hope you disabled/uninstalled kat; it's a huge resource hog and very buggy. Kat is a kde advanced indexing search service that probably runs from kded. Kat has brought many a system to its knees and the overwhelming consensus has been that this beta software should have never been included in the mdv 2006 default installation.

Are you sure about that? I have been receiving Tux Magazine for free since March 2005. That's about the date that I signed up for a free issue and they have been sending me a free issues monthly ever since. I recently received an email from them that I will continue to receive the magazine for free for the next twelve months after which they are going to a for pay model.

I'd remove the dkms package as well. It's suppose to automatically recompile the nvidia driver when you update the kernel but I've found it to be very buggy.

You can try just hand editing /etc/resolve.conf. If you have the ip of a specific nameserver the systax is: nameserver <insert ip> If you have a search domain, the sytax is: search <insert domain name> It's just a matter of adding a line or two per the above and restarting your network. IIRC I've done this in the past without any problem when using dhcp and it seems to have stuck on a reboot. I specifically remember having to manually do this when comcast's dns servers were all screwed up; I had to manually enter the ip of a nameserver that was working.

Go here: http://www.nvidia.com/object/linux_display...2_1.0-8762.html and download the latest nvidia driver(8762). Put it somewhere you can easily find from the command line because that's what you are going to have to do. Boot up and login from the command line as root. Navigate to the directory where you put the nvidia driver and run: # chmod +x NVIDIA-Linux-x86-1.0-8762-pkg1.run # sh NVIDIA-Linux-x86-1.0-8762-pkg1.run That will start the install script and reinstall the nvidia driver. Just keep selecting the "Yes" responses and note any error messages that the installer throws up.

Actually, I believe it's the permissions on the device file that cause the problem. Check out this code: [patrick@localhost ~]$ ls -l /dev/hde brw-rw---- 1 root root 33, 0 Jul 18 04:11 /dev/hde [patrick@localhost ~]$ ls -l /dev/sda brw-rw---- 1 root disk 8, 0 Jul 18 04:11 /dev/sda [patrick@localhost ~]$ ls -l /dev/sdb brw-rw---- 1 root disk 8, 16 Jul 18 04:11 /dev/sdb [patrick@localhost ~]$ ls -l /sbin/mkfs -rwxr-xr-x 1 root root 4920 Sep 19 2005 /sbin/mkfs* mkfs, and things it aliases for, are ordinary user executable. However, the device files are only writable by root and, in the case of devices using the scsi protocol as indicated by /dev/sd*, by root and members of the "disk" group. The scsi protocol is used by scsi hard drives, sata hard drives and usb mass storage devices like flash drives and memory sticks. If you have no scsi or sata hard drives, you could probably solve your problem by adding your user to the disk group. You would also have to change PATH for ordinary users to include /sbin so you wouldn't have to type out "/sbin/mkfs" instead of just "mkfs". Other than that, the only other way I can think of is to write some udev rules for usb mass storage devices that give ordinary users write permissions on their /dev file. It may be doable but it's really beyond me. If interested, check the rules files in /etc/udev/rules.d. Among other things, udev dynamically creates and destroys the device files for usb storage devices when you plug or unplug them. This is all done according the rules in rules.d. Personally, I don't see the need for it. If your on your own box, su to root and format. If your on someone elses box, ask them to do it for you. However, if that's the way you want to set it up, I'm sure it can be done somehow. The really great thing about linux is you can do pretty much anything if you understand it well enough.

Because this just happens all the time. Come on now. It's someone elses box. They will determine what you can and can't do on it, regardless of the fact that its your memory stick. If you want your own rig to run this way, just change the permissions on mkfs to setuid. It's your box afterall; set it up the way that's convenient for you. Most 'nix admins would consider this to be a very insecure practice but if it's just you and your data on there, it's really nobody's business but your own. Heck, you could even run as root all the time and have no such hassles if you want, but I wouldn't recommend that.

The vista bootloader might still be on hde. That's what lilo and grub seem to be picking up as they are both trying to load a windows installation on hde1. I'm suggesting that vista installed it's own bootloader on hde and changed the winxp bootloader to chainload the vista bootlader there. When you ran the winxp fixmbr, it changed its own bootloader on hda but left the vista bootloader on hde intact. Just to test this theory, go into your bios setup and set hde as your first boot hard drive. If you get the vista bootloader screen, then for sure it's still there. If that's the case, you can get rid of the vista bootloader by overwritng it. Post back if the above proves correct and I'll go into more detail.

Well that would be the windows way of doing things. You should realize how horribly insecure this approach has proven to be in practice, even in a single user environment. And in a multiuser environment, this approach would result in complete anarchy.

Most of the people I know that are doing builds are using either NEC or LiteOn for DVD-RW drives. You can usually find a special on them over at newegg: http://www.newegg.com/ProductSort/SubCateg...p?SubCategory=5 Or ZipZoomFly: http://www.zipzoomfly.com/jsp/ProductList....B&Brand=NEC You shouldn't be paying more than around $40 for a decent drive. $60 for an 8X DVD burner is way overpriced when you can get 16X dual layer dvd burners for $40. Both of the above vendors are very reliable and generally recommended by people in the states that do their own builds.

FYI you are suppose to unmount a partition before formatting it; that's probably why you got the error with mkfs. Also, mcc's diskdrake will not show the format option while the partition is mounted. If you unmount the partition you want to format, the format option will appear.

mdk 9.2 used devfs instead of udev. However, pclos 0.93 uses udev and a fairly recent 2.6 kernel(2.6.17?) so I don't think it's a devfs vs udev issue. But give the PnP thing a try anyway; different kernels could react differently to that situation. Another thing to look at is your updates in mdv 2006; make sure you install all the updates. IIRC there were some udev/usb issues in mdv 2006 that were later corrected by the updates.

Post what linux distro you are running, eg mandriva 2006, suse 10.2, etc.

Media player for video: totem or kaffeine Media player for music: amarok Browser: firefox Chat: gaim CD burning: k3b Other: Google Earth(reqires 3d acceleration), Open Office, digikam for digital cameras and photo orginization And games would probably require a whole new thread.

This: /home/lando/Firefox1.5/firefox is not in PATH which means you would have to give the above full path in a console to start your updated firefox. That will probably get old in a real hurry. You can handle that in two ways - you can edit your ~.bash_profile file to add /home/lando/Firefox1.5/ to PATH or you can craeate a link to /home/lando/Firefox1.5/firefox to some directory that is already in PATH. The second is a little easier: $ su <enter root password> # ln -s /home/lando/Firefox1.5/firefox /usr/bin/firefox1.5 After running the above you can launch your new firefox with: $ firefox1.5

You have to give the path to your gentoo kernel image through the device mount point, not through the device file. Try this: 1. Create a directory in your mandriva /boot and name it "gentoo"; 2. Copy kernel-2.6.12-gentoo-r6 from your gentoo /boot to your mandriva /boot/gentoo; 3. Edit your lilo like so: image=/boot/gentoo/kernel-2.6.12-gentoo-r6 label="gentoo" root=/dev/sda2 append="resume=/dev/sda1" vga=788 4. With the external hard drive connected and turned on, rerun lilo. It's important that the external drive that you have gentoo on be connected when you run lilo or you will get an error and lilo will refuse to write your changes to the mbr. Since your gentoo root is set as /dev/sda2, lilo will look and see if such a partition exists; if it doesn't find sda2, it will spit out an error and refuse to go on. If you do the above lilo should write but I can't guarantee that you will be able to boot into gentoo. It will depend in large part what drivers are compiled into your gentoo kernel. If you don't have the drivers in that kernel necessary for dealing with an external usb hard drive, the kernel will load and give a kernel panic when it can't find /dev/sda2.

RMA=Retrun Material Authorization in the warranty of electronic parts lingo. You need vendor authorization to return a defective part under their warranty. They issue you an RMA number that you send with the defective part.

Remove the drive and comment out the line for sda1 in fstab by putting # in front of it. Then try reinserting the drive and see if it automounts. mdv 2006 uses udev and hal to automatically generate the appropriate fstab entry on the fly for removable media and removes that entry from fstab when the device is removed. The fstab entry generated by hal will have the word "pamconsole" in it. If you have a permanent entry in fstab for sda1 like you have, this will overide hal and be used instead on any removable device designated sda1. I'm hoping that the autogenerated fstab entry from hal will work better for you.

You are going to get a lot of anecdotal evidence on the question of which hard drive to get. I don't know how valuable that is - hard drives generally do not fail that often so an individual user's experience is limited. I've only had one hard drive die on me and that was a western digital 4GB hard drive after 6 months back in 1996 or 97. I've never bought another western digital since which is pretty stupid. I think that illustrates my point - people hold these opinions based on fairly random events - in my case the failure of one drive after six months of use. Any of the majors, maxtor, seagate, western digital, are probably equally good. At least it would be hard to scientifically prove one is better than another. To further confound things, they each seem to go through periods where people report problems with drives from one of them. This would indicate that each of the majors is capable of producing a bad batch now and then. Probably the best advice is to stick with the majors and shop price and warranty period. Seagate shook up the industry a while back by lengthening their warranty to 5 years in the US. This was at a time when everyone had gradually scaled back their warranties from three years to one year. That really helped seagate sales to people that build their own rigs.