openoffice.org and ispell
Hi there, I have tried to install openoffice, but it wouldn't peacefully coexist with ispell and related dictionaries; it conflicts with them - I am quite anxious to know why on earth. Has anyone had similar trouble? Is there any way to get ispell and openoffice to coexist with one another? I mean I do appreciate there is a suite such as OO, but I'm not so amused it intends to stomp over everything else there is. I think on a SuSE installation (where I installed OO the anarchic way; some .tgz archive that installed itself), neither program frowned upon the very existence of the other on the disk. So might this simply be an over-strict formulation of interdependencies and the like? Any help appreciated! Florian PS. Don't know whether this is relevant, but I tried packages downloaded as instructed on http://packages.debian.org/unstable/editors/openoffice.org.html, and my distribution is woody stable. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: file and directory permissions question...
Eric,
/foo - Only folks in the 'users' group can read, write and delete
files/dirs.
The permissions of directory foo do not influence whether someone can
open a given file in it for reading or writing, only whether he can
delete, create, or rename a file. Read permission for the directory
means you can read what files are in it, e.g. issue the ls command and
have filename completion. Once someone without read permission to a
directory /knows/ the exact name of a file that's in it, however, he
can write to, read, or execute that file if its permissions permit it.
Precondition to do anything _at_all_ in the directory, however, is to
have execute permission on it (even if you only want to pass
through and do something in a subdirectory).
Thus, the permissions of directory foo rule who is allowed to enter it
at all (= execute permission), read its contents (the filenames and
other information about the files) (= read permission), and who is
allowed to create, rename, or delete files in it (= write permission).
There are, however, two permission bits, which, when set on a
directory, influence something beyond this:
- the sticky bit, when set on a directory, has the effect of
restricting write operations on the directory a little more: to
delete or rename a file within it, it is no more enough to have
write permission to the directory, but you have to be the owner of
either the directory or the file (or the superuser, of course).
- the setgid bit, when set on a directory, causes any new file created
in it to take on the group ownership of the directory, rather than
the default group of the user who created that file.
Thus, for directory /foo, you need an ls -l output like this:
dxrwxrw--- rootusersdate foo
(say 'chmod 770 /foo' and 'chgrp users /foo'). As far as I can see,
this is the closest you can get to what you want: it allows the owner
of the directory (arbitrarily root here) and members of the group
users to create, rename, and delete files inside /foo, as well as get
information _about_ the files in it. It excludes the rest of the
world from doing anything inside it.
/bar - Only folks in the 'admin' group can read, write and delete
files/dirs.
ditto: (say 'chmod 770 /bar' and 'chgrp admin /bar'.
For both: New files/dirs are created as owner=the person that
created it.
This is always the case, AFAIK (no permission bit influences that).
New files/dirs are created as group='users'|'admin', respectively.
Set the setgid bit: say 'chmod 2770 ...' instead of '770'.
User fred is in groups fred,user
User barney is in group barney
User betty is in groups betty,user,admin
I'd like Betty to be able to read/write in both foo and bar.
Barney is hosed, he cannot read or write in neither foo nor bar
I'd like Fred to be able to read/write only in foo.
That should be achieved here; I think your group assignment is
logical.
I've tried logging in as betty and touching a new file in bar, but no
luck (permission denied), even when
drwxrwx--T 13 admin admin 4096 Nov 05 10:52 bar
You have set the sticky bit ('chmod 1770 ...' instead of the setgid
bit, ('chmod 2770 ...'). Permissions in ls -l output must be
'drwxrws---', not 'drwxrwx--T'.
Compare with what is said above: If the sticky bit is set, betty must
be either the owner of the directory (which is not the case: the owner
is called admin), the owner of the file (apparently not her), or the
superuser (apparently not).
Hope this helps,
Florian
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problem with umount/umount2
Sebastian, I have mounted /dev/hde6 as /usr, /dev/hde5 as /home and /dev/hde8 as /var. When I shutdown there is always a message from umount2 that /usr was busy etc, and when I reboot next time it always does the checking of /dev/hde6. The other drives appear to be unmounted cleanly. Postponing the question about what is umount2, have you considered what the manpage says: Note that a file system cannot be unmounted when it is `busy' - for example, when there are open files on it, or when some process has its working directory there, or when a swap file on it is in use. The offending process could even be umount itself - it opens libc, and libc in its turn may open for example locale files. A lazy unmount avoids this problem. I don't suppose this is already the answer, but have you tried 'strace umount'? On my system, this reveals umount does in fact open a few files in /usr (libc6 itself, though, is in /lib). I was interested in this question because I have /usr/lib on a separate partition, which initially caused problems during init, when programs couldn't make their library calls. I run unstable on another machine with 2.4.8, but I do not have this same trouble; man umount does not refer to umount 2. On the Knoppix one, man umount does refer to umount2. Maybe this is too naive and blunt an explanation, but there is a manpage in section 2 (system calls) called umount. Program (section 8, system administration) and system call have the same name. Are you in fact talking about umount(2)? Or is there really a program named umount2? And why is it needed? Curious, Florian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Adding scsi devices ???
Last night, he added a SCSI cdrom and tape drive to the system. He insists that the AIC-7980 controller lists the devices during post. ^^^ =20 What does the underlined expression mean? Are there some messages indicating that the devices are recognised? Where from? Do the devices work? What is the exact problem? Power On Self Test, ie. the SCSI card's BIOS is initialising and listing the devices on the bus during the bit before the OS boots. I see. That would indicate the hardware basically works, I guess. Try modprobe aic7xxx - if it's there, it'll load it... But you still wouldn't know whether the driver is compiled into the kernel or not (though this might be rather rare) -- although: see below. Or does anyone know how to get the .config files for the stock kernels? Don't they end up in /boot? Yes indeed, I just discovered that shortly after writing this (and it is indeed a good idea). I suppose having a glimpse into the file should solve the question. Florian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Incremental CDR backups -- SOLVED
Hello Paul, # Make image mkisofs -r -o /tmp/cdimage /home/paulf/cdrom # Test image mount /tmp/cdimage -r -t iso9660 -o loop /cdrom mc /cdrom To do a more thourough and completely automatic check, I suggest you say 'diff -rq /cdrom /home/paulf/cdrom'. This will, however, yield errors for files which have not changed in future sessions (not in this one, since it is the first). umount /cdrom # Actual burn cdrecord -v -multi speed=4 dev=0,0 /tmp/cdimage # Test CDR mount -t iso9660 -o ro /dev/cdrom /cdrom mc /cdrom see above Some notes: It is possible to determine if a disk has been burned before by checking the results of cdrecord -multi dev=0,0. If empty, then so is the disk. This would allow a script to determine which branch to take (virgin or already burned). You seem to go down about the same path as I did :-) mine does exactly that. Also in testing the above, I also note that sometimes the kernel is dumb about what's on the CDR. Apparently, when testing the image burned on the CDR from later sessions, Linux will sometimes think nothing has changed from the last burn. It appears that if you eject the disk, it usually resolves this problem. This is one suggestion I forgot - but still, I sometimes needed to put the CD-R in a different drive to make the system recognise there was something new on it. I'll mail you the scripts in private. I hope I'll find the time to put it on the Web and also add some documentation (currently, read the file /usr/share/doc/flcdbackup/README.1st about the scattered state of the documentation). Needless to say, any criticism is welcomed. Florian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Adding scsi devices ???
Michael, forgive me if I am just stating the obvious or if I should have missed your point. Last night, he added a SCSI cdrom and tape drive to the system. He insists that the AIC-7980 controller lists the devices during post. ^^^ What does the underlined expression mean? Are there some messages indicating that the devices are recognised? Where from? Do the devices work? What is the exact problem? Assuming nothing works: I'll not cite what you have reported about messages, but the obvious assumption seems - to me - that he does not have the right low level driver either compiled in or as a module. The trouble with the stock kernels is that they lack documentation about what is compiled in and what is not (or am I wrong here?). It is neither entirely clear to me whether your SCSI controller requires the same driver nor that it is _not_ compiled into your kernel. It is only clear you don't have an aic7xxx module. The only remedy I could personally think of would be to compile a kernel from scratch, with the correct driver (well, come to think of it, I think it is principally possible to add a module only, but I suppose you also need a kernel source tree to compile it. But if you can get a binary module somewhere that is compiled for this kernel version, I think it is possible to just load it.). Or does anyone know how to get the .config files for the stock kernels? Florian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mkfs.msdos, FAT 32 and wrong disksize
Lukas writes: I have not had any problems with the schedule: 1 - win fdisk 2 - linux fdisk 3 - win format (for all vfat) 4 - linux mkfs (for all ext2/3) My way for doing things like that: 1 - cfdisk, partion all the disk as you want to 2 - install Windows and re-create the partitions for Windows only (no overhead since this costs only two more keystrokes IIRC). 3 - install Linux -- for safety reasons because it happened some time ago that nice Windows deleted all the things found on a harddisk. I left installing out, since I wasn't sure whether this was part of your needs. Apart from that, your schedule differs only in that you run the (c)fdisks in reverse order (if re-creating the partitions means running Win fdisk prior to installing it). I have basically no idea whether this actually makes any difference. Neither have I any negative experience with doing everything with Linux [c]fdisk (as long as one obeys to Windows' demands), but I just stumbled over the advice and thought if they say it, they must know why... The reason why I would be so cautious is merely that if something is spoiled while partioning and formatting, everything can be assumed to be spoiled. Regards (and wish you success), Florian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [DEB-USER] Re: Incremental CDR backups
Paul writes
There must be something I don't understand about this. For the sake of
brevity, here's an example. First burn is /home/paulf/docs. It contains
the files alfa, bravo, charlie and delta. I make an ISO of this, stored
in /tmp/cdimage. I burn it to CDR and delete the /tmp/cdimage file. A
week later, I've updated the bravo file and added an echo file. Now I
make an ISO of the /home/paulf/docs directory, and burn that to the CDR.
Now when I look on the CDR, what I see is the _original_ burn. All this
is using the commands I mentioned above (normally I'd snip email,
but...).
Now, my original thought was that mkisofs/cdrecord process would simply
add the new echo file, and show an updated version of the bravo file,
while leaving the rest alone. Sort of like the way it works on a hard
drive, except that the space taken up by the old versions of files (like
bravo) would still be used.
To my impression this is roughly the way it works, or more precisely:
if, for the second burn, /home/paulf/docs contains alpha, bravo
(updated), charlie, delta, and echo, mkisofs will not include the
contents of alpha, charlie, and delta in the image but make a sort of
pointer to the files which are already in the previous session instead
(I presume this is why mkisofs needs the information supplied with -C
and -M for all sessions but the first). It will incorporate bravo and
echo.
It is possible to check this if you produce the image if you change
the second number in the argument to -C to 0 (e.g. 12894,0). You can
then mount this image with the loop device, and ls should give all the
filenames present in /home/paulf/docs, but only bravo and echo should
be actually readable, the others should give you error messages or
corrupted data (such an image is not suitable for burning, though,
just for checking).
It should also become obvious if you re-burn an unchanged large
directory which is already in some prior session: the image for the
prior session will be roughly the size of the directory while that for
the repeated session will be only some kB.
These pointers obviously save space, but I guess it would be even more
rational not to include the unchanged files in the image in the first
place.
Bob says
Paul,
Have a look at your mkisofs in your original post above. All you
are doing is re-recoding the contents of your cdrom.
It would be helpful to quote the line you mean here. If it is
(First burn)
mkisofs -r -o /tmp/cdimage /home/paulf/cdrom
cdrecord -v -multi speed=4 dev=0,0,0 -data /tmp/cdimage
(Second burn, after creating a new bunch of stuff to backup)
NEXTTRACK=`cdrecord -msinfo dev=0,0,0`
mkisofs -r -o /tmp/cdimage -C $NEXTTRACK -M /dev/cdrom \
/home/paulf/cdrom
cdrecord -v -multi speed=4 dev=0,0,0 -data /tmp/cdimage
I do not agree, since I think Paul is saying that the contents of
/home/paulf/cdrom have changed.
I do not know exactly why you cannot see the contents of the second
session, but I would try out the following:
- make sure your CD writer is not mounted while burning
- omit the '-data'. I think it is unnecessary and I seem to remember
it has caused trouble with me.
- do not say '-M /dev/cdrom', but '-M 0,0,0'
- mount the CD for checking whether the new files are present not as
you normally would using an fstab entry ('mount /cdrom' or so), but
with explicitly saying something like
mount -t iso9660 /dev/hdb /cdrom
(you have to be root to do that)
- take it out of the CD writer, put it into a different drive capable
of reading CD-ROMs and mount it there to check
Some of these measures have worked for me (as, indeed, the last one!),
some are no more than vague suspicions. If all fails, try out closing
the disk and see whether you can see the other sessions _then_. I
think some drives simply behave like that (if this is the case, it is
a bit unfortunate, because you have to close a disk with incremental
backups prior to restoring the files. Moreover, you cannot check the
files on the CD after the backup.) - ffi, maybe check out
http://www.tldp.org/HOWTO/CD-Writing-HOWTO.html
Would be very interested to know if any of this works.
Florian
PS: in case anyone is interested, I have written two Perl scripts
intended to make full and incremental backups on CD-R more
convenient. The first puts a large number of files on several iso9660
CDs (without any archiving or compression, just like that) and the
second adds sessions to a multisession disk with some safety
measures. The first script also can collaborate with the second by
burning the last disk in multisession mode, so as to make the
remaining space available for further incremental backups. Both are
thoroughly tested by myself and work fine for me, although the
session-adding script is sometimes provoking errors from the SCSI
adaptor driver. This should be a problem of the latter (beta), not of
the
xkbdcomp reports mysterious error
When running X, I get the following error message from the server: The XKEYBOARD keymap compiler (xkbcomp) reports: Error:No Symbols named [EMAIL PROTECTED]@ in the include file de Exiting Abandoning symbols file default Errors from xkbcomp are not fatal to the X server This is quite plausible, since although the right keyboard layout is chosen in XF86Config (pc104 and de), two keys do not work as supposed, namely AltGr and Bksp, which are interpreted as Alt_R and Delete, respectively (reported by xev). Now although I'm not even sure whether Debian uses xmodmap or xkb, this error message clearly seems to hint that it uses the latter, and that the error is the reason of the problem. Can anybody tell me what it means? Does the symbol xkbdcomp looks for make sense, or is something seriously broken? Thanks for any help! Florian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mkfs.msdos, FAT 32 and wrong disksize
Dear all, don't ask why but I have to prepare a disk with FAT32. I won't ask ;-) , but if you happen to have also Windows on your machine, I think I have an advice. To my experience, FAT32 is the only way to really share a partition between Linux and Windows (i.e., have the same access to it). I have also tried mkfs.msdos and have also got errors I did not even understand because I know too little about VFAT. AFAIK, Linux FAT support is still *alpha* (though I think this refers to creating and checking such a filesystem, rather than using it), for which reason I suspect it is wisest to make the filesystem (format the disk, as they say) under Windows. The second reason is that if (and only if) you intend to use the partition under Windows as well, you want to be sure it accepts the fs. Linux mkfs.msdos, however, has quite a few fine-tuning options, which seems -- to me -- nothing less than asking for trouble. Yeah, my advice would be: play it safe. Format one of those partitions with Windows, and then check again about the sizes. My bet is that everything will be as supposed. Another advice is taken from the fdisk manpage: For best results, you should always use an OS-specific partition table program. For example, you should make DOS partitions with the DOS FDISK program and Linux partitions with the Linux fdisk or Linux cfdisk program. I would follow that. True, the Win fdisk is very unwieldy (if not stupid) and lets you do things in a certain sequence only. That should not be a problem if you are sure what to do. I have not had any problems with the schedule: 1 - win fdisk 2 - linux fdisk 3 - win format (for all vfat) 4 - linux mkfs (for all ext2/3) [I think under Windows, in some cases it can be important for the drive letters not to change once they're recorded - or registered or whatever.] Hope this is still accurate (as far as the alpha status of FAT support is concerned - I am using Woody) and helps, Florian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: du and df problem... Please help!
I'm afraid I can't help you directly, and with my system, df and du behave more like you would expect. The ideas I did have seemed a bit too straightforward to myself. Anyway, allow me to ask one or two questions to get it clearer: When I run du on each root directory (ie. /boot, /dev, etc), I totaled up the sizes given for each directory, the total OS size is reported as being around 22mb. Have you also tried running it on / (du -s /)? If I run the df command, I get a total OS size of 55mb. Hmm. Maybe it uses a block size of 512 Bytes instead of 1024 (see the manpage)? Although 55 instead of 44 is still a considerable deviation ... I have no mounts to anything (my mtab file only contains /dev/hda3 (which is my root partition) and the proc fs). Have you also checked this by saying mount without any arguments? Come to think of it, I suggest you post the output of du -s /, the output of df, and the output of mount (together with the exact commandline you used) - that way it's easier to see how you have calculated your figures. Florian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
