Re: Bash scripts
kevin wrote: Sascha: Continued to play with this. Went into nautilus on an ext2 formatted card, and there is a checkbox in the panel for allowing execution of files. The owner and other permission boxes didn't seem to do anything; but, clicking that on *did* work. Also, you were correct about it needing to not be FAT, checking that box, even though it sill displays, didn't 'stick' for FAT. Thanks. i've lost track of where exactly this issue sits, but if it's a regression, i suggest opening a ticket. then it can be resolved in a documented fashion (whether fixed as bug or wontfixed as a feature). paul Cheers, KG On Monday, April 18, 2011, Kevin Gordon kgordon...@gmail.com wrote: Sascha: The file system actually had no bearing on the issue I was having, whether ext2, ext3, or FAT32, the symptoms were identical - recent versions of udisks now does not allow 'direct' execution of scripts from auto-mounted removable media. Also, there is some debate as to whether putting a journalling fs onto an SD or USB drive is wise, as it might half its life by in essence doubling the number of writes. In general, I tend to stick with the factory default unless I need multiple partitions, symbolic link, or specific linux-swap support, since I presume the manufacturer has formatted it with the right number of blocks, units, etc to best match their controller/memory config. If I need those, I will still use ext2. Call me optimistic :-) Cheers, KG On Mon, Apr 18, 2011 at 4:13 AM, Sascha Silbe sascha-ml-reply-to-201...@silbe.org wrote: Excerpts from Kevin Gordon's message of Mon Apr 18 00:36:26 +0200 2011: But, since my main use of this technique is to semi-automate the process of installing a slew of custom activities and rpm's upon initial build and deployment, having to manually change every machine manually to basically avoid 5 keystrokes, was sort of counter-productive :-) If you're only using this USB stick with Linux machines, why don't you just format it using a file system with POSIX semantics, i.e. ext3? Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bash scripts
Excerpts from Kevin Gordon's message of Sun Apr 17 17:19:36 +0200 2011: any build before. Log in as root (su -) Write a little script - it can be a one liner, echo Hello World is good enough. Save it as test.sh to a USB stick which has been formatted FAT32 and has a volume name FEDORA. Do a Chmod +x /media/FEDORA/test.sh. Let me provide another piece of the puzzle: FAT is the file system that was designed for DOS. Unlike the older Unix systems DOS didn't have the concept of permissions, so neither has FAT. Assignment of ownership and permissions for FAT file systems is always based on heuristics, controlled by mount options. For your case the options exec/noexec (file system independent), umask, fmask and showexec (FAT only) are relevant. If you want real POSIX permissions support on a FAT file system, you need to use umsdos [1]. Make sure you understand the principles of operation and the associated drawbacks first, esp. if you use the same USB stick with other systems that do not run umsdos. Nobody I know ever went to the trouble of using it, not even when most of our systems were still running OS/2. Sascha [1] http://tldp.org/HOWTO/UMSDOS-HOWTO.html -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: PGP signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bash scripts
Excerpts from Kevin Gordon's message of Mon Apr 18 00:36:26 +0200 2011: But, since my main use of this technique is to semi-automate the process of installing a slew of custom activities and rpm's upon initial build and deployment, having to manually change every machine manually to basically avoid 5 keystrokes, was sort of counter-productive :-) If you're only using this USB stick with Linux machines, why don't you just format it using a file system with POSIX semantics, i.e. ext3? Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: PGP signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bash scripts
On Mon, Apr 18, 2011 at 10:13:56AM +0200, Sascha Silbe wrote: If you're only using this USB stick with Linux machines, why don't you just format it using a file system with POSIX semantics, i.e. ext3? I don't know about Kevin, but for me some USB flash drives become slower at writing of large files, when converted from factory formatted FAT to ext3. It is as if the flash translation layer in the USB drive was optimised for FAT. Adjusting the starting position of the partition can do this as well. ext3 also has this journal thing, which presumably increases the number of writes. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bash scripts
Sascha: The file system actually had no bearing on the issue I was having, whether ext2, ext3, or FAT32, the symptoms were identical - recent versions of udisks now does not allow 'direct' execution of scripts from auto-mounted removable media. Also, there is some debate as to whether putting a journalling fs onto an SD or USB drive is wise, as it might half its life by in essence doubling the number of writes. In general, I tend to stick with the factory default unless I need multiple partitions, symbolic link, or specific linux-swap support, since I presume the manufacturer has formatted it with the right number of blocks, units, etc to best match their controller/memory config. If I need those, I will still use ext2. Call me optimistic :-) Cheers, KG On Mon, Apr 18, 2011 at 4:13 AM, Sascha Silbe sascha-ml-reply-to-201...@silbe.org wrote: Excerpts from Kevin Gordon's message of Mon Apr 18 00:36:26 +0200 2011: But, since my main use of this technique is to semi-automate the process of installing a slew of custom activities and rpm's upon initial build and deployment, having to manually change every machine manually to basically avoid 5 keystrokes, was sort of counter-productive :-) If you're only using this USB stick with Linux machines, why don't you just format it using a file system with POSIX semantics, i.e. ext3? Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bash scripts
El Sun, 17 Apr 2011 11:19:36 -0400 Kevin Gordon kgordon...@gmail.com escribió: Perhaps one could conjecture that this is some added security, or new property for execution of scripts resident on portable drives that has been implemented. However, as for 'filing a bug report', it looks like it's something way upstream from my pay-class, since it isn't limited to OLPC, but occurs across Fedora 14 updated machines too. I've not checked, but probably the filesystem is being mounted with the noexec option. Anyway, it's a feature, not a bug. signature.asc Description: PGP signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bash scripts
Jerry Vonau For the WIN! A yum downgrade udisks reinstalls the 1.0.1-4 package and makes it behave just like before. Nice little green file-names on teh ls output, the ability to run scripts from USB drives without the bash command returns, and tab complete functions again.. Again, since this package is used all through fedora, (and on Ubuntu too, I think), I doubt little old me should be telling the upstream world how it should work. Cheers, KG On Sun, Apr 17, 2011 at 12:54 PM, Jerry Vonau jvo...@shaw.ca wrote: On Sun, 2011-04-17 at 11:19 -0400, Kevin Gordon wrote: Martin and the Gang: Since last we spoke, I've been working on this new issue I'd mentioned, where when I try to run a bash shell script resident on a USB drive inserted into an OS16 OLPC, I always get Permission Denied. But now, I'm not sure it's a bug; and if so, I'm now pretty sure it isn't an OLPC bug. Here are the details to reproduce. Go to terminal on a 10.1.3 Build 860, or any build before. Log in as root (su -) Write a little script - it can be a one liner, echo Hello World is good enough. Save it as test.sh to a USB stick which has been formatted FAT32 and has a volume name FEDORA. Do a Chmod +x /media/FEDORA/test.sh. One can then take that USB stick to any previous-to-Fedora 14 OLPC, and execute the script by simply installing the drive, logging into root (su -), going to the terminal prompt, and entering /media/FEDORA/test.sh, and see the old 'Hello World' come up - not Permission Denied. One can also tab complete through that command, and it sees and auto-completes the test.sh portion too, So, I tried on a vanilla little lenovo with a fresh unaltered installation of the Fedora14 Live-Desktop. The script runs fine from the USB drive. Then after accepting and installing the 422 recommened Software Updates on the box, this box too now gives Permission Denied. I repeated this same procedure twice more with fresh installs, then updates. Very consistent,, works before updates, does not work after. On the OLPC side, I did a more binary search, and the script continues to work right up to and including os5 from the 11.2 builds. At os6, and after, is where the Permission Denied starts to occur when attempting to execute. Not surprisingly, and concurrently, the tab complete capability on the test.sh portion ceases to function at this point as well. Alas, someone upstream might now consider this a feature, not a bug. Also, someone upstream might be able to figure out which of those 422 packages is responsible, if they should care to. Partial diff between os5.packages.txt os6.packages.txt -udisks-1.0.1-4.fc14.i686 +udisks-1.0.2-2.fc14.i686 Jerry ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bash scripts
On Sun, Apr 17, 2011 at 4:28 PM, Kevin Gordon kgordon...@gmail.com wrote: Again, since this package is used all through fedora, (and on Ubuntu too, I think), I doubt little old me should be telling the upstream world how it should work. Bingo. It's a security feature -- avoids the situations where you plug in a usb drive and accidentally double-click on something and kaboom. Your workaround #2 (bash /media/foo/myscript.sh) is what I'd do. You can also mount -o remount,exec /media/foo cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bash scripts
Thanks all, I'll reinstall back up to the OS16 version of udisks and enter 'bash ' before the script name. Just FYI, there were some other novel suggestions involving policy kit oerrides, fstab entries, and even some other funky flag settings. But, since my main use of this technique is to semi-automate the process of installing a slew of custom activities and rpm's upon initial build and deployment, having to manually change every machine manually to basically avoid 5 keystrokes, was sort of counter-productive :-) Cheers and thanks again. KG. On Sun, Apr 17, 2011 at 6:05 PM, Martin Langhoff martin.langh...@gmail.comwrote: On Sun, Apr 17, 2011 at 4:28 PM, Kevin Gordon kgordon...@gmail.com wrote: Again, since this package is used all through fedora, (and on Ubuntu too, I think), I doubt little old me should be telling the upstream world how it should work. Bingo. It's a security feature -- avoids the situations where you plug in a usb drive and accidentally double-click on something and kaboom. Your workaround #2 (bash /media/foo/myscript.sh) is what I'd do. You can also mount -o remount,exec /media/foo cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
