Fedora for UltraSPARC?
by Chris Adams
Is anyone working on getting Fedora working on UltraSPARC systems? I am
aware of Aurora SPARC Linux, but I would like to run the same thing as I
run on my x86 systems.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
20 years, 1 month
Tettnang ??
by Brian Millett
Ok, so why a town in Germany?
--
Brian Millett
Enterprise Consulting Group "Shifts in paradigms
(314) 205-9030 often cause nose bleeds."
bpmATec-groupDOTcom Greg Glenn
20 years, 1 month
rawhide report: 20040515 changes
by Build System
Updated Packages:
fedora-release-2-rawhide
------------------------
rpmdb-fedora-2-0.20040515
-------------------------
20 years, 1 month
Re: systematic Kerberization
by Simon Wilkinson
I'm coming somewhat late to this party, having been pointed at the
discussion by a colleague. Apologies for the length of this mail.
I developed the authentication and directory services infrastructure for
the Division of Informatics at the University of Edinburgh, as part of
this work I wrote the SSHv2 GSSAPI implementation in OpenSSH, along with
investigating and patching numerous other pieces of Kerberos code.
Laptops are a key part of the computing infrastructure here, and we have
looked into the disconnected authentication problem in some detail.
The key missing piece, for us, is web applications. There are a number
of solutions floating around, from that recently implemented in Mozilla
(Microsoft's Negotiate solution), to UMICH's kx509 technology.
Unforunately, most web applications use their own in built
authentication methods, making it hard to substitute new technologies.
In addition, delegation is of critical importance to services which
interface against other Kerberized backends (webmail, for example), and
doesn't appear to be cleanly supported by any of the current solutions.
Its also critical to assess the correctness of a given applications
Kerberos implementation. There are 'Kerberised protocols' which merely
perform a Kerberos handshake upon connection establishment, and then
allow the rest of the conversation to occur unprotected. These are
obviously vulnerable to MITM attacks unless carried over an already
encrypted _and authenticated_ channel. (HTTP Negotiate, and postgres's
Kerberos authentication are both examples of this).
The killer application is probably still email. It would be good to see
a wide spread of Kerberised IMAP and POP clients, along with MUAs which
support SMTP-AUTH. The criticial application here for us is Mozilla.
CUPS is worrying, as it seems that the authentication options are a step
backwards from those available with LPRng.
The SSH support that's now in OpenSSH is suitable for small sites, but
the lack of key exchange makes it hard to deploy over large sites, who
are trying to avoid having to manage yet another set of key material.
I'm trying to find the time at present to update my key exchange patches
to both the newest releast of the I-D, and the current OpenSSH code base.
It would also be really nice to have a better solution for securing the
nss -> LDAP server link with GSSAPI. Ideally, it would be possible to
run a caching daemon on each machine which would manage Kerberos
credentials for contacting the LDAP server, which the nss libraries
would go through to gain access.
Onto disconnected operation ...
Locally, we've put a lot of time and effort into making disconnected use
of our machines 'just work'. From an authentication and directory
services point of view we've got fairly far along that path.
We take the view that there are two different 'tokens' that a user must
have in order to access a machine - the first provides local access, and
the second to network services. At the moment, these 'tokens' are
identical - the user has the same password for both local and network
access.
The decision to combine the two was arrived at for operational and
usability reasons. We can envisage having a large number of disconnected
machines, possibly more than one per user. Expecting users to remember
different 'local' passwords for every machine and to change them all at
the same time seemed like a nightmare. In addition, managing these local
accounts centrally means that its easier to guarantee that password
strength requirements are met.
We provide a tool for renewing credentials which works like 'kinit', but
uses the PAM stack in order to allow the chaining of other
authentication mechanisms (such as kx509). Users who have logged in
whilst their machine is disconnected must use it after reconnecting
their machine, and before accessing network resources.
Disconnected directory services are a hard problem, which I don't think
we've got right yet. We currently mirror substantial chunks of our LDAP
service to the local machine, which just isn't scalable as the volume of
directory information grows. However, not having it there creates
problems when increasing chunks of the machine depend on it.
Hope all thats of use!
Cheers,
Simon.
20 years, 1 month
kernel panic with ivtv on amd64, firmware loading and test_ioctl work fine!
by Sven Boeckelmann
hi im trying to run ivtv on an amd64-
ok, the firmware loading has been fixed.
used : http://kmos.org/~ckennedy/ivtv/ivtv-0.1.10-pre2-ck65f.tgz
to load ivtv successfully.
but the io code does not seem to be 64bit safe.
when accessing the device the kernel crashes:
when executing function ivtv_sched_DMA
There must be someone out there who is able to check if this
is 64bit safe .. !
Thanks,
sven
PS: if someone can tell me how to save the dmesg of a crashing kernel
i will submit the stack trace
On Fri, 2004-05-14 at 13:46, Sven Boeckelmann wrote:
> hi,
>
> i'm trying to get ivtv working on my amd64.
> the driver is compiling on gentoo with kernel 2.6.6, gcc 3.3.3,
> module-init-tools from gentoo sys-apps/module-init-tools-3.0
>
>
> but when i'm doing insmod i get a modprobe Ooops:
>
> ivtv: i2c client attach
> ivtv: i2c attach [client=saa7115[0],ok]
> ivtv: Active card count: 1.
> ivtv: Stopping VDM
> ivtv: Stopping AO
> ivtv: pinging (?) APU
> ivtv: Stopping VPU
> ivtv: Resetting Hw Blocks
> ivtv: Stopping SPU
> ivtv: Sleeping for 10ms
> ivtv: init Encoder SDRAM pre-charge
> ivtv: init Encoder SDRAM refresh to 1us
> ivtv: init Decoder SDRAM pre-charge
> ivtv: init Decoder SDRAM refresh to 1us
> ivtv: Sleeping for 600ms (600 recommended)
> ivtv: Card ready for firmware!
> ivtv: Loading encoder image
> ivtv: Loading decoder firmware
> ivtv: Sleeping for 1 sec
> ivtv: Sleeping for 1 sec
> ivtv: About to search for mailboxes
> ivtv: Searching for encoder mailbox
> ivtv: .<1>Unable to handle kernel paging request at 00000000000c8100
> RIP:
> <ffffffffa02ebdfb>{:ivtv:ivtv_find_firmware_mailbox+75}PML4 38949067 PGD
> 386ad067 PMD 0
> Oops: 0000 [1]
> CPU 0
> Pid: 5714, comm: insmod Tainted: P 2.6.6
> RIP: 0010:[<ffffffffa02ebdfb>]
> <ffffffffa02ebdfb>{:ivtv:ivtv_find_firmware_mailbox+75}RSP:
> 0018:0000010037529dc8 EFLAGS: 00010213
> RAX: ffffff00010c7fff RBX: 0000000000000000 RCX: 000000000000007f
> RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffffff80463a40
> RBP: 00000000000c8100 R08: 0000000000000034 R09: 000001003f37b0c0
> R10: 0000007fbffff3c3 R11: 0000000000000001 R12: 0000000000000000
> R13: ffffffffa02fd720 R14: 00000000005020a0 R15: 0000000000000003
> FS: 0000002a95ac9060(0000) GS:ffffffff804ce600(0000)
> knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 00000000000c8100 CR3: 0000000000101000 CR4: 00000000000006e0
> Process insmod (pid: 5714, stackpage=1003e76f000)
> Stack: 0000000000000000 ffffffffa02fd720 000001003fd15000
> 0000000000000000
> 0000000000000000 ffffffffa03056b0 0000010037529e80
> 01164000381e1aa8
> 000001003ff0c3a8 ffffffff801948b1
> Call Trace:<ffffffffa03056b0>{:ivtv:ivtv_probe+1712}
> <ffffffff801948b1>{sysfs_create+113}
> <ffffffff801951a3>{create_dir+131}
> <ffffffff8022d3cd>{pci_device_probe_static+61}
> <ffffffff8022d419>{__pci_device_probe+25}
> <ffffffff8022d460>{pci_device_probe+48}
> <ffffffff8028aad7>{bus_match+71}
> <ffffffff8028abf6>{driver_attach+70}
> <ffffffff8028ae9e>{bus_add_driver+126}
> <ffffffff8028b212>{driver_register+50}
> <ffffffff8022d68e>{pci_register_driver+62}
> <ffffffffa02ef1ac>{:ivtv:module_start+716}
> <ffffffff80148417>{sys_init_module+263}
> <ffffffff8011141a>{system_call+126}
>
>
> Code: 8b 45 00 39 04 95 70 ae 2f a0 75 54 ff c3 44 8d 65 04 8d 43
> RIP <ffffffffa02ebdfb>{:ivtv:ivtv_find_firmware_mailbox+75} RSP
> <0000010037529dc8>
> CR2: 00000000000c8100
>
>
> i was able to track it down to this portion of the code,
> but i guess the ivtv code is not able to 64bit at all.
> I habe been in contact with some of the ivtv developers,
> but none of them use amd64. so it's hard for them to figure out
> where the problem is. I was hoping someone on this list can help.
>
> int ivtv_find_firmware_mailbox(struct ivtv *itv) {
> u32 *searchptr, *result;
> int match = 0;
>
> searchptr = NULL;
> result = NULL;
>
> IVTV_DEBUG(IVTV_DEBUG_INFO, "Searching for encoder mailbox\n");
> searchptr =(u32 *)(IVTV_FIRM_SEARCH_ENCODER_START +
> itv->io_mem);
>
> while (searchptr < (u32 *)(IVTV_FIRM_SEARCH_ENCODER_END +
> itv->io_mem)) {
> if (ivtv_firm_search_id[match] == readl(searchptr)) {
> (u32)result = (u32)searchptr+4; /* avoid pointer
> aritmetic */
> match++;
> while ((match > 0) && (match < 4)) {
> IVTV_DEBUG(IVTV_DEBUG_INFO, "match:
> 0x%08x at "
> "0x%08x. match: %d\n",
> *result,
> (u32)result, match);
> if (ivtv_firm_search_id[match] ==
> readl(result)) {
> match++;
> /* FIXME change to just
> "result++;" ? */
> (u32)result = (u32)result + 4;
> }
> else
> match = 0;
> }
> }
> else {
> IVTV_DEBUG(IVTV_DEBUG_INFO, ".");
> }
> if ( 4 == match ) {
> IVTV_DEBUG(IVTV_DEBUG_INFO, "found encoder
> mailbox!\n");
>
> itv->enc_mbox = (struct ivtv_mailbox *) result;
> break;
> }
> (u32)searchptr += IVTV_FIRM_SEARCH_STEP;
> }
> if (itv->enc_mbox == NULL) IVTV_DEBUG(IVTV_DEBUG_ERR, "Encoder
> mailbox not found\n");
>
> IVTV_DEBUG(IVTV_DEBUG_INFO, "Searching for decoder mailbox\n");
> match = 0;
> searchptr = (u32 *)(IVTV_FIRM_SEARCH_DECODER_START +
> itv->io_mem);
>
> while (searchptr < (u32 *)(IVTV_FIRM_SEARCH_DECODER_END +
> itv->io_mem)) {
> if (ivtv_firm_search_id[match] == readl(searchptr)) {
> (u32)result = (u32)searchptr+4; /* avoid
> pointer aritmetic */ match++;
> while ((match > 0) && (match < 4)) {
> IVTV_DEBUG(IVTV_DEBUG_INFO, "match:
> 0x%08x at 0x%08x. match: %d\n",
> *result, (u32)result, match);
> if (ivtv_firm_search_id[match] ==
> readl(result)) {
> match++;
> /* FIXME change to just
> "result++;" ? */
> (u32)result = (u32)result + 4;
> }
> else
> match = 0;
> }
> }
> else {
> IVTV_DEBUG(IVTV_DEBUG_INFO, ".");
> }
> if ( 4 == match ) {
> IVTV_DEBUG(IVTV_DEBUG_INFO, "found decoder
> mailbox!\n");
> itv->dec_mbox = (struct ivtv_mailbox *) result;
> break;
> }
> (u32)searchptr += IVTV_FIRM_SEARCH_STEP;
> }
> if (itv->dec_mbox == 0) IVTV_DEBUG(IVTV_DEBUG_ERR, "Decoder
> mailbox not found\n");
>
> return 0;
> }
>
>
> the first time we run into the loop everything is fine,
> but after
> (u32)searchptr += IVTV_FIRM_SEARCH_STEP;
> is called
> readl(searchptr)
> causes the error.
>
> i did a quick hack and changed it to:
> searchptr = (u32 *) (searchptr + IVTV_FIRM_SEARCH_STEP);
> which eliminated the error.
>
> but of course id didn't make the driver work properly :-(
>
> no the encoder search loop works, but doesn't find a match at
> if (ivtv_firm_search_id[match] == readl(searchptr)) {
>
> and when we start looking for the decoder there is still the same error.
>
> i guess there is something going wrong with ivtv->io_mem and
> readl(searchptr).
>
> unfortunately i don't know much about pointer and address ranges.
> I'm hoping to get in touch with one of the amd64 kernel gurus on this
> list to help us figure out how to get ivtv running on amd64.
>
> I'm really stuck!
>
> Cheers,
> Sven
20 years, 1 month
Yum.conf in rawhide.
by Carwyn Edwards
I've just synced with devel and found this in the yum.conf.rpmnew:
distroverpkg=redhat-release
.. should this not be fedora-release?
Carwyn
20 years, 1 month
glibc-kernheaders?
by Daryll Strauss
The current release of glibc-kernheaders is 2.4-8.44.
This includes linux/version.h and states the version is 2.4.20.
I assume this is a mistake, right?
- |Daryll
20 years, 1 month
Fedora treats security as a joke.
by StoneBeat
I want to warn about the way that Fedora treats security, i'm a compulsive
reader of security lists like bugtraq, and I've never seen some security
advisor published by Fedora Security Coordinator (or something like that) as
I've seen in other distros (Debian, Gentoo, SuSE ....) about notifying some
important security advisors.
With regularly I am checking for updates using yum and see that there are new
RPM updates. I believe that in these updates are the security fixes but I
really don't know it because there aren't advisors.
I fed up and i did a little research about security and Fedora, so i took some
quite old security advisor relating "lha". Some people found security bugs in
these tool, you can see more info here:
http://www.securiteam.com/unixfocus/5LP000KCVC.html
Today many distros have the appropriate security advisor and patch, one of
these distros is RedHat: http://rhn.redhat.com/errata/RHSA-2004-179.html
but Fedora users don't have security advisor or security patch, i check yum
and I don't see anything about lha and the lha version shipped with Fedora
Core 1 is vulnerable:
[ice@laptop ice]$ rpm -qa | grep -i lha
lha-1.14i-12
[ice@laptop ice]$ lha x buf_oflow.lha
LHa: Error: Unknown information
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU
Segmentation fault
[ice@laptop ice]$
Where is the security advisor ??? and the security patch ???
Why Fedora doesn't have a security coordinator or even a security team ??
20 years, 1 month
rawhide report: 20040512 changes
by Build System
Updated Packages:
elilo-3.4-5
-----------
* Mon May 10 2004 Jeremy Katz <katzj(a)redhat.com> - 3.4-5
- update efibootmgr to 0.5.0-test3 adding sysfs support (#122566)
fedora-release-2-4
------------------
fedora-release-2-5
------------------
file-4.07-4
-----------
* Mon May 10 2004 Jakub Jelinek <jakub(a)redhat.com>
- fix ELF note handling (#109495)
* Tue Mar 23 2004 Karsten Hopp <karsten(a)redhat.de> 4.07-3
- add docs (#115966)
* Tue Mar 02 2004 Elliot Lee <sopwith(a)redhat.com>
- rebuilt
glibc-2.3.3-27
--------------
* Tue May 11 2004 Jakub Jelinek <jakub(a)redhat.com> 2.3.3-27
- remove /lib64/tls/librtkaio-2.3.[23].so in glibc_post_upgrade
on x86-64, s390x and ppc64 instead of /lib/tls/librtkaio-2.3.[23].so
- build mq_{send,receive} with -fexceptions
im-sdk-11.4-43
--------------
* Mon May 10 2004 Warren Togami <wtogami(a)redhat.com> 1:11.4-43
- im-sdk-11.4-htt-local-permit.patch: Allow htt connections when DNS does not match
Fixes CJK for many users. FC2 BLOCKER #121480
mozilla-1.6-8
-------------
* Mon May 10 2004 Christopher Blizzard <blizzard(a)redhat.com> 37:1.6-8
- Make sure that MOZ_APP_NAME is defined so that a non-empty property is
set on the moz window.
* Mon May 10 2004 Christopher Blizzard <blizzard(a)redhat.com> 37:1.6-7
- Add a -a mozilla to the client in the startup script so that it will
only talk to mozilla instances
rpmdb-fedora-2-0.20040512
-------------------------
udev-024-6
----------
* Mon May 10 2004 Elliot Lee <sopwith(a)redhat.com> 024-6
- Turn off udevd by default for FC2
up2date-4.3.19-1
----------------
* Tue May 11 2004 Adrian Likins <alikins(a)redhat.com>
- point sources at the new correct repo urls
- merge some multilib fixes from RHEL3 branch
* Fri May 07 2004 Adrian Likins <alikins(a)redhat.com>
- fix #122088 (arch->noarch updates)
yum-2.0.7-1.1
-------------
* Tue May 11 2004 Elliot Lee <sopwith(a)redhat.com> 2.0.7-1.1
- Update config again
20 years, 1 month
