Tiny Core Linux
Tiny Core Extensions => TCE Q&A Forum => Topic started by: aus9 on January 29, 2013, 09:42:15 PM
-
Hi
I am thinking of relaxing the mount rules for udisks policy and I noticed the following
whether I upgrade and request tcz upgrade or keep local I will defer to your good looks and judgement ok?
target file=
usr/local/share/polkit-1/actions/org.freedesktop.udisks.policy
from tcz =
polkit.tcz
Some parts of this file is in Danish
current syntax
<action id="org.freedesktop.udisks.filesystem-mount">
<description>Mount a device</description>
<description xml:lang="da">Montér en enhed</description>
<message>Authentication is required to mount the device</message>
<message xml:lang="da">Autorisering er påkrævet for at montere et fil system</message>
<defaults>
<allow_any>no</allow_any>
<allow_inactive>no</allow_inactive>
<allow_active>yes</allow_active>
</defaults>
</action>
Proposed syntax
<action id="org.freedesktop.udisks.filesystem-mount">
<description>Mount a device</description>
<description xml:lang="en">Mount a device</description>
<message>Authentication is NOT required to mount the device</message>
<message xml:lang="en">Authorisation is NOT required to mount a file system,</message>
<defaults>
<allow_any>yes</allow_any>
<allow_inactive>yes</allow_inactive>
<allow_active>yes</allow_active>
</defaults>
</action>
EDIT change to udisks policy
also edit the eject policy
more later after testing
2) Naturally being an idiot I tried to overwrite the current location as above but its read only file as that is how TC works.
possible options
a) create my own tcz and swap it in
b) muck about with the current unpack at /tmp and replace it
c) tcz may be out-of-date so request upgrade options or possible change of downstream maintainer
any other ideas?
thanks for reading
3) I think it may have impact on those currently running
sudo umount /mnt/pathway to unmount a device
-
What about just overwriting the link with the original file, edit it and add to backup?
-
hmm not sure if I understood so lets show
sudo su
pwd
/tmp/tcloop/polkit/usr/local/share/polkit-1/actions
cp -f org.freedesktop.policykit.policy /usr/local/share/polkit-1/actions/
cp: `org.freedesktop.policykit.policy' and `/usr/local/share/polkit-1/actions/org.freedesktop.policykit.policy' are the same file
cheers
any other ideas or should I just remaster the tcz?
-
Looks like the file has already been copied...
Not sure what would prevent you from editing it then.
-
I can always copy the source file from /tmp pathway.....that has not been an issue
What I am trying to do is change one policy file
EDIT
ensure I have an unmodified tcz by checking updates thru apps panel
same result
sorry to be verbose, the tmp file is sym linked to the /usr folder, I assume you knew this.
I can't do the reverse copy as thats just a sym link file trying to overwrite the original
or did I mis-understand your earlier post
2) Of course I have already remastered but if I planned to submit to repository I can't,
I am not the original mantainer
So what I was trying to do.....was work with an existing tcz and over-write one of its file's
Does that clear it up?
I have no problem working with a locally created tcz, replacing the existing tcz but that is not what I am looking to do........I am looking for a fresh tcz that interacts with the existing tcz with an info file warning of the relaxed ruleset for just one policy.
anyhow thanks for reading.
-
I will waffle on a bit here to try and dumb it down for me to understand
tcz unpacks into /tmp and has a source file at certain location
I will call that file A
B is a sym link from A but with new pathway under /usr
I want to introduce a new file called C
that replaces (ultimately) B
-
In no case extensions extract into /tmp.
They are simply stored in /tmp in default mode and in mount mode mounted under /tmp/tcloop and files symlinked to /, while in copy mode they are unpacked to /.
squashfs is a read-only fs and can not be modified.
To modify a file contained in an extension, either the squashfs gets loopmounted and then the file copied to a read-write fs or unsquashed with "unsquashfs".
-
Hi aus9
cp: `org.freedesktop.policykit.policy' and `/usr/local/share/polkit-1/actions/org.freedesktop.policykit.policy' are the same file
I think I ran into that once too and had to remove the symlink and then copy.
-
well my system (and I hope most others) has their tcz "stored" under /tmp and sym linked
So I am guessing between the two responses I might try this
1) a separate tcz has a file lets say /usr/local/lib/something but not doing anything until tce.installed script acts by
2) removes the sym link file but does not interfere with the "stored" /tmp file
3) script then .....sym links from /usr/local/lib/something pathway to old deleted sym link file pathway (effectively replacing the old sym link file with a changed version)
-----to act as a replacement which is my current goal
who knows I could not work it out by myself and I am just playing at the moment to see what can be done. I will test out tomorrow if I have time as proof of concept
cheers
-
The extensions are loop mounted under /tmp/tcloop/extension_name.
If you want to make a file editable, then you have the start-up script copy the file from its loop mounted location into the usual file system location.
For example: #!/bin/sh
[ -f /usr/local/etc/bluetooth/main.conf ] || cp -p /usr/local/share/bluez/files/main.conf /usr/local/etc/bluetooth/
..i.e. if a conf file exists, don't do anything but, if it doesn't exist, then copy the default conf file to the default location so it can be edited if so required.
-
If I understood correctly, OP intends to overwrite the default config file with an already modified one, sourced in a separate extension.
-
I do this kind of stuff quite regularly, here is what I just did for some fuse config file that was not editable. After this I generally also put a reference to the file into /opt/.filetool.lst so that it will be backed up.
cp /usr/local/etc/init.d/fuse tmp
sudo rm /usr/local/etc/init.d/fuse
sudo cp tmp /usr/local/etc/init.d/fuse
-
...... are the same file
That message, it least in my case, is coming from the coreutils version of cp. Using /bin/cp will overwrite the link.
-
just realized I was editting the wrong policy file
I have editted top post....its an udisks policy file
will report back when I can....other things arise
thanks heaps everyone