-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
I have an old computer with suse 7.3 on it (the latest it can use: it is a
pentium classic with 32 MB). I used the other day to ssh to my main
computer (opensuse 10.3) and kill a process that had locked the keyboard).
It has it's small uses.
Today I tried to ssh to it, and i can't: the ssh session stays for ever
like this:
cer@nimrodel:~> ssh telperion.valinor
never asking for the password. What is going on? It worked with 10.2, I
think.
I know it is not a network issue. It may be related to an authentication
method that has changed defaults in 10.3, but I don't know what exactly.
There is no entry in the logs.
- --
Cheers,
Carlos Robinson
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Made with pgp4pine 1.76
iD8DBQFHQZUDtTMYHG2NR9URAlG7AJ4pLwjrRwgeT/pzMrCNOabhhfSz8QCbB1NM
AAjxA7IdKLe3VV6owEpKlKA=
=a/67
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-security+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-security+help(a)opensuse.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I have an encripted filesystem inherited from 10.2 and before. I have this
line in fstab:
/biggy/crypta_f.mm.x /mnt/crypta.mm.x xfs noauto,user,noatime,nodiratime,loop,encryption=twofish256 1 4
Reading from this filesystem works (I'm copying it elsewhere now).
Writing to this filesystem, from another similarly encripted filesystem,
large files (between 300 and 400 MB), locks the console where the copy is
having place. The copy process stops. It is unkillable. Umount of that
filesystem locks (and umount is unkillable). Reboot filesystem locks.
If I try to "ls -l" the destination dir of the copy (that is locked,
frozen) also freezes.
I have to lazy umount ("umount -l /mountpoints &") all the mountpoints I
can, and then try to reboot (which hangs) and then poweroff the machine
forcefully.
There is absolutely nothing in the logs relative to this problem (I know
how to look into logs).
I have fsck the filesystem, nothing:
nimrodel:~ # losetup -e twofish256 /dev/loop2 /biggy/crypta_f.mm.x
Password:
nimrodel:~ # file -s /dev/loop2
/dev/loop2: SGI XFS filesystem data (blksz 4096, inosz 256, v2 dirs)
nimrodel:~ # xfs_check /dev/loop2
ERROR: The filesystem has valuable metadata changes in a log which needs to
be replayed. Mount the filesystem to replay the log, and unmount it before
re-running xfs_check. If you are unable to mount the filesystem, then use
the xfs_repair -L option to destroy the log and attempt a repair.
Note that destroying the log may cause corruption -- please attempt a mount
of the filesystem before doing this.
nimrodel:~ # mount /dev/loop2 /mnt/crypta.mm.x/
nimrodel:~ # umount /dev/loop2
nimrodel:~ # xfs_check /dev/loop2
nimrodel:~ #
No errors.
I'm aware that the encription filesystems have changed in 10.3, but the
only document I have is the release notes. Probably I would have to use a
different method than losetup, but I have no idea which. An encripted
filesystem I see it uses devmap.
But notice that the problem arises from a filesystem mounted directly from
fstab - shouldn't this method be used now anymore?
In any case, the "classic" method should freeze the computer, as it does :-?
- --
Cheers,
Carlos Robinson
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Made with pgp4pine 1.76
iD8DBQFHTiu2tTMYHG2NR9URAr5gAJwNybIdLLBs5NTiirEehsYUOUzKOwCeN0s3
+FOv7HWC2FOfojUrCKae3r4=
=WgTn
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-security+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-security+help(a)opensuse.org
I found LUKS recently through SUSE Linux 10.3,
and the other night a read an article in c't 2006/11.
I can't seriously appreciate the technical internals,
as I'm not too compentent there.
Anyway: Kudos to Clemens Fruhwirth!
But I am not really sure, whether I can trust, what I read in that article regarding the master key,
spefically that the master key can be read from the LUKS volume by the sys admin without any difficulties.
Does that really mean, that as soon as somebody gains control over my computer with a mounted LUKS encrypted (external) disc
and he also manages to gain root priviliges,
that he can retrieve the necessary information,
to mount that disc himself with LUKS-means again?!?
I mean without me passing the keys to him.
If that is seriously so,
I think I will have to find myself another disc encryption toolset,
as I cannot tolerate, that intruders can deal with my personal data without my explicit permission and support.
Whether those intruders have governmental permissions, I don't f...ing care.
I appreciate your serious comments.
J.
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-security+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-security+help(a)opensuse.org
Hello everybody,
yesterday one of my webservers refused to deliver any more webpages, while
reaching the server with ssh was fine and the load of the server was very
low. But there were 100 apache processes, which is the configured limit on
that server. Usually there are about 30 apache processes.
In /var/log/messages I found some messages like this at the same time:
Nov 19 14:38:12 server1 kernel: TCP: Treason uncloaked! Peer
87.160.97.54:2560/80 shrinks window 1710186274:17
10191335. Repaired.
Does anyone know what this means and how it might be related to the apache
processes? Ist this some kind of DoS attack?
cu, Magnus
--
Carl Magnus Rosenbaum M.A.
Administration - Programmierung - Weiterbildung http://cmr.cx/
Tel: +49 89 70066626 Fax: +49 89 70066686 Mobil: +49 163 7006662
PGP Fingerprint: DEBC 3C99 EF1D 74F0 D4C7 EFF5 C268 3690 0EA1 7641
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
According to the release notes, I thought that /etc/cryptotab was to be
converted to /etc/crypttab while upgrading 10.2 to 10.3, but it wasn't.
How do I do it?
The entry in /etc/cryptotab is this:
/dev/loop0 /dev/disk/by-id/ata-ST3320620A_5QF2M56F-part15 /cripta xfs twofish256 noatime,nodiratime
I see a man page for crypttab, which says that the lines should be:
<target device> <source device> <key file> <options>
But I don't see clearly. It says:
· The first column, target device specifies the mapped device
name. It must be a plain filename without any directories. A
mapped device /dev/mapper/device name will be created by
cryptsetup(8) crypting data from and onto the source device.
To actually mount that device it needs to be listed in
/etc/fstab.
Ie, is it an invented name? A non existing name in /dev/mapper/? Like
/dev/mapper/MyCrypto?
Then the line would be:
MyCrypto /dev/disk/by-id/ata-ST3320620A_5QF2M56F-part15 ....
Now, third field:
· The third column key file specifies the file to use for
decrypting the encrypted data of the source device. It can
also be a device name (e.g. /dev/urandom, which is useful for
encrypted swap devices). Warning: luks does not support
infinite streams (like /dev/urandom), it requires a fixed size
key.
Are they talking of the mount point? A file containing the passphrase? I
believe the second.
· The fourth field options specifies the cryptsetup options
associated with the encryption process. At minimum, the field
should contain the string luks or the cipher, hash and size
options. Options have to be specified in the format:
key=value[,key=value ...]
Cipher, hash, size.... I have no idea how to relate this to the original
remaining options:
... xfs twofish256 noatime,nodiratime
Is this suppossed to be this way? I don't see how...
- --
Cheers,
Carlos Robinson
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Made with pgp4pine 1.76
iD8DBQFHTi9/tTMYHG2NR9URAtJ8AJ9+7Cm5VwCEh/PTE93iKzTJh+a1+ACfdB6q
yEAJUTkmAeAg4EBsAEDXDRA=
=YGOD
-----END PGP SIGNATURE-----
+unsubscribe
_____________________________________________________________________
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=000000000066
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-security+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-security+help(a)opensuse.org
Hola Carlos
On 30/11/2007, Carlos E. R. <robin.listas(a)telefonica.net> wrote:
>
> That's very nice - at least for the people creating new encrypted
> filesystems. Mine are older, some created for SuSE 9.2, maybe before.
> Those on the hard disk I can recreate, and probably I will; but those in
> DVD I can't. In my fstab I already have 4 (four) different entries to
> mount DVDs created using 4 different methods over time.
>
> Now I guess I have to create a new '5' method for DVDs using LUKS, which I
> hope will last longer, as the options are written inside somehow :-)
>
>
Don't you think that it would be more convenient (and a lot of less
troublesome) to copy all those four DVDs to new ones encrypted with
LUKS? Do you have to access them through a disparate number of
systems? You could set up a proxy to access the new LUKS-encrypted
ones.
Just my two cents :-)
--
Saludos
Paco Cruz
---------------------------------------------------------------------
If you think that training is expensive and complicated, try ignorance instead.
Roy Crock (founder of McDonalds)
Si crees que el aprendizaje es caro y complicado, prueba con la ignorancia.
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-security+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-security+help(a)opensuse.org
Hello everyone.
Automatic weekly updates stopped working after I did a
rpm -e zmd-updater zen rug
for OpenSUSE 10.2 machines.
If this is my fault,
configuring (again) automatic update in yast should warn me that
automatic updates will not work.
Greetings
Sven
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
There is no snort in 10.3. Why?
- --
Cheers,
Carlos Robinson
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Made with pgp4pine 1.76
iD8DBQFHSg8ItTMYHG2NR9URAmbIAJ4/XfzorMHrTclNlUpf1g+WC3k9fACfWbRW
8/8bLrVwfLyYbiqZW/InBBs=
=KMUJ
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-security+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-security+help(a)opensuse.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
YOU says it wants to update:
bug-buddy
java-1_5_0-sun
java-1_6_0-sun
updates-alternatives
Knowing about last Friday problem, I'm suspicious - and yes, there are
conflicts again:
#### YaST2 conflicts list - generated 2007-11-20 01:20:48 ####
Cannot install java-1_6_0-sun-plugin, because it is conflicting with java-1_5_0-sun-plugin
A conflict over java-1.3.1-plugin (java-1.3.1-plugin) requires the removal of java-1_6_0-sun-plugin-1.6.0.u3-0.5.i586[gwdg-update] which is scheduled for installation
=== java-1_6_0-sun-plugin-1.6.0.u3-0.5.i586[gwdg-update] ===
java-1_6_0-sun-plugin-1.6.0.u3-0.5.i586[gwdg-update] is needed by atom:java-1_6_0-sun-plugin-1.6.0.u3-0.5.i586[gwdg-update] (java-1_6_0-sun-plugin >= 1.6.0.u3-0.5)
sed-4.1.5-64.i586 is needed by java-1_6_0-sun-plugin-1.6.0.u3-0.5.i586[gwdg-update] (sed == 4.1.5-64)
findutils-4.2.31-24.i586 is needed by java-1_6_0-sun-plugin-1.6.0.u3-0.5.i586[gwdg-update] (/usr/bin/find)
=== java-1_5_0-sun-plugin-1.5.0_update13-0.5.i586[gwdg-update] ===
java-1_5_0-sun-plugin-1.5.0_update13-0.5.i586[gwdg-update] is needed by atom:java-1_5_0-sun-plugin-1.5.0_update13-0.5.i586[gwdg-update] (java-1_5_0-sun-plugin >= 1.5.0_update13-0.5)
(null)
Conflict Resolution:
( ) do not install java-1_6_0-sun-plugin
( ) do not install java-1_5_0-sun-plugin
(X) Ignore this conflict of java-1_6_0-sun-plugin
atom:bug-buddy cannot be installed due to missing dependencies
There are no installable providers of bug-buddy >= 2.20.1-1.1 for atom:bug-buddy-2.20.1-1.1.i586[gwdg-update]
=== atom:bug-buddy-2.20.1-1.1.i586[gwdg-update] ===
atom:bug-buddy-2.20.1-1.1.i586[gwdg-update] is needed by patch:bug-buddy-4686-0.noarch[gwdg-update] (bug-buddy == 2.20.1-1.1)
bug-buddy-2.20.1-1.1.i586[gwdg-update] provides bug-buddy == 2.20.1-1.1, but it is uninstallable. Try installing it on its own for more details.
(null)
Conflict Resolution:
(X) do not install bug-buddy
( ) Ignore this requirement just here
#### YaST2 conflicts list END ###
And I try again, and I get the same conflict with a different text,
impossible to understand unless you are a Yast programmer :-(
#### YaST2 conflicts list - generated 2007-11-20 01:23:12 ####
Cannot install java-1_6_0-sun-plugin, because it is conflicting with java-1_5_0-sun-plugin
A conflict over java-1.4.2-plugin (java-1.4.2-plugin) requires the removal of java-1_6_0-sun-plugin-1.6.0.u3-0.5.i586[gwdg-update] which is scheduled for installation
=== java-1_6_0-sun-plugin-1.6.0.u3-0.5.i586[gwdg-update] ===
java-1_6_0-sun-plugin-1.6.0.u3-0.5.i586[gwdg-update] is needed by atom:java-1_6_0-sun-plugin-1.6.0.u3-0.5.i586[gwdg-update] (java-1_6_0-sun-plugin >= 1.6.0.u3-0.5)
sed-4.1.5-64.i586 is needed by java-1_6_0-sun-plugin-1.6.0.u3-0.5.i586[gwdg-update] (sed == 4.1.5-64)
findutils-4.2.31-24.i586 is needed by java-1_6_0-sun-plugin-1.6.0.u3-0.5.i586[gwdg-update] (/usr/bin/find)
=== java-1_5_0-sun-plugin-1.5.0_update13-0.5.i586[gwdg-update] ===
java-1_5_0-sun-plugin-1.5.0_update13-0.5.i586[gwdg-update] is needed by atom:java-1_5_0-sun-plugin-1.5.0_update13-0.5.i586[gwdg-update] (java-1_5_0-sun-plugin >= 1.5.0_update13-0.5)
(null)
Conflict Resolution:
( ) do not install java-1_6_0-sun-plugin
( ) do not install java-1_5_0-sun-plugin
(X) Ignore this conflict of java-1_6_0-sun-plugin
patch:bug-buddy cannot be installed due to missing dependencies
There are no installable providers of bug-buddy == 2.20.1-1.1 for patch:bug-buddy-4686-0.noarch[gwdg-update]
=== patch:bug-buddy-4686-0.noarch[gwdg-update] ===
patch:bug-buddy-4686-0.noarch[gwdg-update] will be installed by another application. (ApplLow/ApplHigh)
atom:bug-buddy-2.20.1-1.1.x86_64[gwdg-update] is needed by patch:bug-buddy-4686-0.noarch[gwdg-update] (bug-buddy == 2.20.1-1.1)
atom:bug-buddy-2.20.1-1.1.ppc[gwdg-update] is needed by patch:bug-buddy-4686-0.noarch[gwdg-update] (bug-buddy == 2.20.1-1.1)
atom:bug-buddy-2.20.1-1.1.i586[gwdg-update] provides bug-buddy == 2.20.1-1.1, but it is locked.
(null)
Conflict Resolution:
( ) unlock bug-buddy
( ) unlock all resolvables
(X) do not install bug-buddy
( ) Ignore this requirement just here
#### YaST2 conflicts list END ###
So I answer the same thing as before, and get a third conflict:
#### YaST2 conflicts list - generated 2007-11-20 01:25:45 ####
Cannot install java-1_6_0-sun-plugin, because it is conflicting with java-1_5_0-sun-plugin
A conflict over java-1.4.1-plugin (java-1.4.1-plugin) requires the removal of java-1_6_0-sun-plugin-1.6.0.u3-0.5.i586[gwdg-update] which is scheduled for installation
=== java-1_6_0-sun-plugin-1.6.0.u3-0.5.i586[gwdg-update] ===
java-1_6_0-sun-plugin-1.6.0.u3-0.5.i586[gwdg-update] is needed by atom:java-1_6_0-sun-plugin-1.6.0.u3-0.5.i586[gwdg-update] (java-1_6_0-sun-plugin >= 1.6.0.u3-0.5)
sed-4.1.5-64.i586 is needed by java-1_6_0-sun-plugin-1.6.0.u3-0.5.i586[gwdg-update] (sed == 4.1.5-64)
findutils-4.2.31-24.i586 is needed by java-1_6_0-sun-plugin-1.6.0.u3-0.5.i586[gwdg-update] (/usr/bin/find)
=== java-1_5_0-sun-plugin-1.5.0_update13-0.5.i586[gwdg-update] ===
java-1_5_0-sun-plugin-1.5.0_update13-0.5.i586[gwdg-update] is needed by atom:java-1_5_0-sun-plugin-1.5.0_update13-0.5.i586[gwdg-update] (java-1_5_0-sun-plugin >= 1.5.0_update13-0.5)
(null)
Conflict Resolution:
( ) do not install java-1_6_0-sun-plugin
( ) do not install java-1_5_0-sun-plugin
(X) Ignore this conflict of java-1_6_0-sun-plugin
#### YaST2 conflicts list END ###
I get the same, and I answer the same:
#### YaST2 conflicts list - generated 2007-11-20 01:26:40 ####
Cannot install java-1_6_0-sun-plugin, because it is conflicting with java-1_5_0-sun-plugin
A conflict over java-1.4.0-plugin (java-1.4.0-plugin) requires the removal of java-1_6_0-sun-plugin-1.6.0.u3-0.5.i586[gwdg-update] which is scheduled for installation
=== java-1_6_0-sun-plugin-1.6.0.u3-0.5.i586[gwdg-update] ===
java-1_6_0-sun-plugin-1.6.0.u3-0.5.i586[gwdg-update] is needed by atom:java-1_6_0-sun-plugin-1.6.0.u3-0.5.i586[gwdg-update] (java-1_6_0-sun-plugin >= 1.6.0.u3-0.5)
sed-4.1.5-64.i586 is needed by java-1_6_0-sun-plugin-1.6.0.u3-0.5.i586[gwdg-update] (sed == 4.1.5-64)
findutils-4.2.31-24.i586 is needed by java-1_6_0-sun-plugin-1.6.0.u3-0.5.i586[gwdg-update] (/usr/bin/find)
=== java-1_5_0-sun-plugin-1.5.0_update13-0.5.i586[gwdg-update] ===
java-1_5_0-sun-plugin-1.5.0_update13-0.5.i586[gwdg-update] is needed by atom:java-1_5_0-sun-plugin-1.5.0_update13-0.5.i586[gwdg-update] (java-1_5_0-sun-plugin >= 1.5.0_update13-0.5)
(null)
Conflict Resolution:
( ) do not install java-1_6_0-sun-plugin
( ) do not install java-1_5_0-sun-plugin
( ) Ignore this conflict of java-1_6_0-sun-plugin
#### YaST2 conflicts list END ###
So, a third time I say to ignore, and this time it shuts up.
Why is this nonsense? I should install both 1_5 and 1_6 patches:
cer@nimrodel:~/.ssh> rpm -q java-1_6_0-sun-plugin java-1_5_0-sun-plugin
java-1_6_0-sun-plugin-1.6.0.u3-0.3
java-1_5_0-sun-plugin-1.5.0_update13-0.3
but yast complains about conflicts, even if the initial screen says there
are patches for both that I should apply.
What is this all about?
Finally, it says it is going to install:
java-1_5_0-sun
java-1_5_0-sun-plugin
java-1_6_0-sun
java-1_6_0-sun-alsa
java-1_6_0-sun-jdbc
java-1_6_0-sun-plugin
updates-alternatives
- --
Cheers,
Carlos Robinson
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Made with pgp4pine 1.76
iD8DBQFHQiuttTMYHG2NR9URAmCAAJoDgnwczaRlojPnITiJwaQ1eTfZwQCfdDlH
FjreVByN6egkwUjcjCI4hBE=
=U8/O
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-security+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-security+help(a)opensuse.org