Re: Letting Ordinary Users Write To Disk Key
by Jef Spaleta
Robert L Cochran wrote, somewhere in the digest:
>I have a 128 Mb disk key plugged into my test machine. Severn recognizes
>it, and I've formatted and mounted the thing as '/mnt/dkey'. How can I
>give an ordinary user (namely, me) write access to it?
i would suggest these fstab options:
noauto,owner
and then i would suggest making sure /etc/security/console.perms
is setup to understand the /dev/ and /mnt/ listings for yer Diskkey.
The owner option is pretty slick, it tries to restrict access to devices
and files based on which is user is physically logged into the console.
Sure its overkill for a single user system...but its still slick. I try
to use this for all my removable media fstab listings.
-jef"the real question is...when will rhl support a boot 'floppy' mode
for something like a usb keydrive"spaleta
20 years, 9 months
Re: updates
by Jef Spaleta
Michael Young wrote, somewhere in the digest:
>What I can't stress enough is the fact updates for the RHEL beta are
>already in RHN. A beta is a beta, be it RHEL or RHL. So if RH is going
>to release updates for one beta on RHN, why can't they do it for the
>other beta as well?
Actually...RHL is now a 'project' RHEL is still a 'product'...i don't
think how the beta phases for RHL and RHEL are going to look the same,
from this point forward (and i dont think the community at large is
going to want them to). And frankly...since the language at the rhl
webpages, seemed to have redefined what rawhide is going to be used
for....i don't think using up2date for pushing bugfix packages is going
to make sense really... My view of how rhn has been used in beta phases
in the past, has been more about testing rhn functionality, than
providing a service to beta tester to get a stream of updates.
IF the rhlp, is serious about making this a broader community
development effort, then there needs to be a community way to push
updates around. RHN, like it or not....is a redhat support service for
redhat products.
I'd imagine that at someone there will be updates to a beta channel, in
an effort to test up2date functionality against the beta..to make sure
up2date is working. But i think is a logic error in assuming that RHN
will be the prefered mechanism to get RHLp beta package updates from
this point forward. More likely than not community based proggies like
apt and yum will end up being the preference, if the development process
does broaden out into the community.
>Everyone seems to be saying I can't use the tools I "purchased" if I
>want to run the betas. So, if I don't want to throw away my money,don't
>beta test. That attitude does not make me feel very welcome in the
>development community.
Here is where you apply a little logic.
Redhat does not support the beta releases. RHN is essential a support
service...for supported products. The expectation that RHN can be used
to update the beta..ever..just don't make a lot of sense. RHN is not
part of this community 'project'. There needs to be a community based
way of pushing updates around between iso sets...yum apt etc....rhn is
not there to help developers...id imagine rhel is getting active rhn
updates becuase rhel is still a redhat 'product' and is not going to
open up to community based decision making,and a lot of closed beta
testing is going on inhouse for the RHEL stuff. RHLp isn't going to get
that kind of inhouse private beta testing anymore...so rhl.redhat.com
had me believe when i read it.
I would never buy an entitlement for a beta release...then again i would
never obliterate a functional redhat install that i need working with a
beta either. I buy entitlements to cover my home desktops...and then i
beta test a seperate install. I register that beta install with rhn, and
I wait. When i see updates for the beta, I go to rhn flip the
entitlement over to the beta box just long enough to get the beta
updates and switch it back. You can't be sure there will EVER be
updates in RHN, I don't know why you expect them...don't bank on
it..don't buy the entitlement for the beta system. I seriously doubt
anyone at redhat expects you to buy entitlements for the beta....and it
takes minimal effort to switch an active entitlement over when and if
you need to test rhn on the beta install.
But lets talk about the issue of what would happen if redhat gave
everybody running a beta install a freebie entitlement. Everyone would
run a beta install...and redhat's rhn bandwidth would get munched by
beta updates...not cool. If this really is going to be a more open
development project...then there needs to be a community way to push
updates around during these beta phases. RHN is a redhat service, which
does need its own amount of beta testing, but its not a community based
service...at least not yet...have to wonder if the idea of 3rd party
channel through rhn tied to say yum repos will gain a little traction
if redhat ever get around to targeting the home desktop userbase.
Now that the language surrounding what rawhide is suppose to be has
changed(according to the rhl website when i read it) there needs some
community based ways to get access to those beta updates that appear in
rawhide.
-jef"wouldn't it be great if i could configure my up2date client to look
for updates on community add-on channels like fedora? Or failing
that...having an applet icon notifier that would work in a similar way
for apt or yum based repos i could use to give me a heads up about
updates"spaleta
20 years, 9 months
Re: updates
by Jef Spaleta
Michael Young wrote, somewhere in the digest:
>I'm tired of hearing "it's not supported." I didn't ask for "support,"
>I just asked why the updates for Severn weren't available from RHN, whil
>the updates for Taroon are. And, so far, I received an answer from
>everyone but a Red Hat employee (well, not everyone, but you get the
>point).
Simple answer...there are no updates...wait for them to appear....if
they appear..be happy. The key here is don't expect updates to ever ever
ever appear. And don't work under the assumption that RHEL betas and RHL
betas are anywhere close to the same thing. So what if RHEL beta has
updates in rhn...where is it written rhn is going to carry updates
between beta isos? For all you know RHEL is getting updates through rhn
to test rhn functionality. RHL has a published(well it did at
rhl.redhat.com when that site was working) schedule pointing out when
the next iso set will appear...I didnt see any mention about published
updates outside of rawhide between those iso sets.
>I am also concerned that I will not be able to use the remainder of my
>subscription on the next release of RHL. That would force me to keep my
>systems at RH9, or quit using my entitlements, which will cost me money.
This is a concern well outside the bounds of this list. I can't speak
for Red Hat's plan for rhn and their next non enterprise product
release. All i can say is that if they were to stop offering updates
through rhn for their non enterprise line of products...I'd have no need
for the rhn service and I would not re-up my subscription in the future.
But your concern about future redhat releases and rhn is very much
outside the scope of this beta list....but personally i think you'd be
better off asking the world governments about their plan in case of a
massive asteroid strike on the earth, i think that's probably a higher
likelihood..so you should spend you effort on that concern before
getting worked about about rhn.
>I guess I will re-install my "supported" product, quit making an effort
>to contribute to the community, and go on about my business...
Nice parting shot. Yeesh...is this how you handle every time someone
disagrees with you or tells you your concerns are not a big priority to
them...you just take your ball and go home? If you are really
interesting in running the beta and contributing, you have a few
options. The chances of these options changing, because you threaten to
reinstall rhl9 are pretty low. Your options are:
1)just use the isos sets...report bugs..wait for next iso
this is by far the safest course of action...
2)keep watching that up2date icon...and if it shows there is an update
present, go to rhn switch yer active entitlements around and get the
beta updates. DO NOT EXPECT updates to appear.
3)watch an ftp mirror or yum/apt/autoupdate/grab repository for updates
4)watch rawhide and eat relevant rawhide packages as they come
out...since it seems now this time around rawhide's been redefined to be
more beta relevant...so rhl.redhat.com would make me believe.
RHN is NOT RHLp. If you NEED RHN to work for you, and you don't have a
spare system...then you are probably better off not using the beta at
all. I can't for the life of me understand why you would pay for an
entitlement for a stable system, then choose to replace that system with
a beta. At no point in the past has anyone said that rhn would
definitely provide updates for betas...certaintly not security
updates(which if you look back is pretty much the main reason rhn is
used for in the redhat releases)...we saw this last time around with the
sendmail security vulnerability that showed up right before the last
release.
I think you have some misconceptions about the service rhn
provides...the point of beta releases in general...and the point about
contributing to a community effort....you brought up a concern. I
thought the reference to a previous mharris post about what 'support'
means in a beta summed up the general point: once you install the
beta...you can't expect to see one single update package ever! If they
show up...they show up. And as for rawhide, the day to day packages that
show up in rawhide should still be taken with as much concern as in the
past i think. Rawhide packages could easily break as much as they
fix...its not clear to me that its in every beta tester's best interest
to eat rawhide on a daily basis. Every beta tester..if yer going to beta
test should run the isos and report bugs, and follow up on their
specific bugreports if a developer pushes updates to rawhide...but i
don't know if every beta tester should be using the daily rawhide
updates for all the packages...and expect to end up with a system that
is better of than before.
-jef"heading off to write to his congressmen about that asteroid strike
preparedness plan"spaleta
20 years, 9 months
RE: alsa and no sound
by Pavel Rosenboim
> -----Original Message-----
> From: Mike [mailto:mike@redtux.demon.co.uk]
> Sent: Sun, August 03, 2003 3:38 AM
> To: severn
> Subject: Re: alsa and no sound
>
>
> On Sat, 2003-08-02 at 16:04, Joel Young wrote:
> > From: Mike <mike(a)redtux.demon.co.uk>
> > >On Sat, 2003-08-02 at 04:58, Gerald Henriksen wrote:
> > >> By default alsa mutes the inputs and outputs on a
> soundcard and you
> > >> must use alsamixer to unmute them (m key) as well as increase the
> > >> level as necessary.
> > >thanks
> > >
> > > now - any idea how to stop it doing it?
> >
> > How is:
> >
> > post-install sound-card-0 /usr/sbin/alsactl restore
> >/dev/null 2>&1 || :
> > pre-remove sound-card-0 /usr/sbin/alsactl store >/dev/null 2>&1 || :
> >
> > in modules.conf
> >
>
> tried this (but in /etc/modprobe.conf - using 2.6-test2)
>
> what I get is
> ignoring badline at for both of these commands ie:
>
> Aug 3 01:16:14 localhost modprobe: WARNING:
> /etc/modprobe.conf line 14:
> ignoring bad line starting with 'pre-remove'
> Aug 3 01:16:36 localhost modprobe: WARNING:
> /etc/modprobe.conf line 13:
> ignoring bad line starting with 'post-install'
The syntax of modprobe.conf is different from that of modules.conf - there
are no pre-install/pre-remove statements.
Try using something like this:
install sound-card-0 /sbin/modprobe --ignore-install sound-slot-0 && {
/usr/sbin/alsactl restore >/dev/null 2>&1 || : }
remove sound-card-0 {/usr/sbin/alsactl store >/dev/null 2>&1 || : };
/sbin/modprobe -r --ignore-remove sound_slot_0
>
>
> > I think that covers what you want.
> >
> > Joel
> >
> >
> > --
> > Rhl-beta-list mailing list
> > Rhl-beta-list(a)redhat.com
> > http://www.redhat.com/mailman/listinfo/rhl-beta-list
>
>
> --
> Rhl-beta-list mailing list
> Rhl-beta-list(a)redhat.com
> http://www.redhat.com/mailman/listinfo/rhl-beta-list
>
20 years, 9 months
sb and sound
by guran
Hi
AFAIK the /etc/modprobe.conf.dist should contain all known setups or writings
for drivers to be copied to /etc/modprobe.conf, and I can't find the lines
for sb. Something is missing in modprobe.conf.
Here is from my box:
....
>From /var/log/messages:
Aug 3 10:52:45 Pelles gdm(pam_unix)[2615]: session opened for user guran by
(uid=0)
Aug 3 10:52:55 Pelles kernel: Soundblaster audio driver Copyright (C) by
Hannu Savolainen 1993-
1996
Aug 3 10:52:55 Pelles kernel: sb: Creative SB AWE64 PnP detected
Aug 3 10:52:55 Pelles kernel: sb: ISAPnP reports 'Creative SB AWE64 PnP' at
i/o 0x220, irq 5, d
ma 1, 5
Aug 3 10:52:55 Pelles kernel: SB 4.16 detected OK (220)
Aug 3 10:52:55 Pelles kernel: sb: 1 Soundblaster PnP card(s) found.
Aug 3 10:52:55 Pelles modprobe: modprobe: Can't locate module
sound-service-0-0
Aug 3 10:52:55 Pelles modprobe: modprobe: Can't locate module sound-slot-1
Aug 3 10:52:55 Pelles modprobe: modprobe: Can't locate module
sound-service-1-0
Aug 3 10:52:55 Pelles modprobe: modprobe: Can't locate module sound-slot-1
Aug 3 10:52:55 Pelles modprobe: modprobe: Can't locate module
sound-service-1-0
>From /etc/modules.conf:
alias eth0 8139too
alias usb-controller usb-uhci
alias sound-slot-0 sb
post-install sound-slot-0 /bin/aumix-minimal -f /etc/.aumixrc -L >/dev/null
2>&1 || :
pre-remove sound-slot-0 /bin/aumix-minimal -f /etc/.aumixrc -S >/dev/null 2>&1
|| :
alias synth0 awe_wave
>From /etc/modprobe.conf:
include /etc/modprobe.conf.dist
alias eth0 8139too
.....
regards
guran
--
Red Hat Linux Beta 9.0.93 kernel-2.4.21-20.1.2024.2.1.nptl
Only in a society that has 'a priori' defined what is true
can the result from the evolution of life be defined false.
20 years, 9 months
RE: 2.6.0- test2, getting sound to work?
by Pavel Rosenboim
> -----Original Message-----
> From: Gerald Henriksen [mailto:ghenriks@rogers.com]
> Sent: Fri, August 01, 2003 6:31 AM
> To: rhl-beta-list(a)redhat.com
> Subject: Re: 2.6.0- test2, getting sound to work?
>
>
> On Thu, 31 Jul 2003 22:57:57 -0400 (GMT), you wrote:
>
> >and do we have a volunteer to go back over the last 20+
> >posts regarding ALSA sound under test-2.6.0 and summarize all
> >that into a nice, condensed recipe? i've seen enough 2.6.0
> >kernel today to last me a while.
>
> I've made a note to put together a list of instructions including a
> couple of links into the ALSA website tomorrow.
>
> Having said that anyone know why after 3 boots twice the driver hasn't
> been loaded automatically and I have had to do "modprobe snd-emu10k1"
> from a command prompt? This is my current stuff for sound in
> /etc/modprobe:
Try to use an underscore instead of dash : alias snd_card_0 snd-emu10k1...
I played with it and somehow I got alsa to work without any manual
interaction.
>
> alias char-major-116 snd
> alias snd-card-0 snd-emu10k1
> alias char-major-14 soundcore
> alias sound-slot-0 snd-card-0
> alias sound-service-0-0 snd-mixer-oss
> alias sound-service-0-1 snd-seq-oss
> alias sound-service-0-3 snd-pcm-oss
> alias sound-service-0-8 snd-seq-oss
> alias sound-service-0-12 snd-pcm-oss
> alias char-major-116 snd
> alias snd-card-0 snd-emu10k1
> alias char-major-14 soundcore
> alias sound-slot-0 snd-card-0
> alias sound-service-0-0 snd-mixer-oss
> alias sound-service-0-1 snd-seq-oss
> alias sound-service-0-3 snd-pcm-oss
> alias sound-service-0-8 snd-seq-oss
> alias sound-service-0-12 snd-pcm-oss
>
>
> --
> Rhl-beta-list mailing list
> Rhl-beta-list(a)redhat.com
> http://www.redhat.com/mailman/listinfo/rhl-beta-list
>
20 years, 9 months
RE: VNC installation
by Pavel Rosenboim
> -----Original Message-----
> From: Bernd Bartmann [mailto:Bernd.Bartmann@sohanet.de]
> Sent: Thu, July 31, 2003 9:19 PM
> To: rhl-beta-list(a)redhat.com
> Subject: Re: VNC installation
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Felipe Alfaro Solana wrote:
> | On Thu, 2003-07-31 at 20:04, Pavel Rozenboim wrote:
> |
> |
> |>Just installed severn over VNC. It just worked.
> |>Great job :)
> |
> |
> | How did you do that?
> | I'm *really* curious about it...
>
> It's explained in the release notes. Just pass "vnc" as kernel boot
> parameter. The only problem I had with this is that you have
> to manually
> assign an IP address to the system using ifconfig on console #2. I've
> already filed a bug in bugzilla on this issue.
Hmm.. I did't have such problem. I booted as 'linux expert vnc' and at some
point install just asked me for network settings.
>
> VNC install is definitely a really cool new feature.
>
> Best regards.
>
> - --
> Dipl.-Ing. (FH) Bernd Bartmann <Bernd.Bartmann(a)sohanet.de>
> I.S. Security and Network Engineer
> SoHaNet Technology GmbH / Kaiserin-Augusta-Allee 10-11 / 10553 Berlin
> Fon: +49 30 214783-44 / Fax: +49 30 214783-46
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.1 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQE/KV2ZkQuIaHu84cIRAiGjAJ9KKAYrhyoptV/y24S07tnQNaa7bACeMBIJ
> NUn1ajR0DaZorzOoqkKpoLA=
> =w5nf
> -----END PGP SIGNATURE-----
>
>
> --
> Rhl-beta-list mailing list
> Rhl-beta-list(a)redhat.com
> http://www.redhat.com/mailman/listinfo/rhl-beta-list
>
20 years, 9 months
Re: Re: 2.6.0- test2, getting sound to work?
by Robert P. J. Day
-------Original Message-------
From: Gerald Henriksen <ghenriks(a)rogers.com>
> Any apps on freshrpms that are compiled to use ALSA require the
> alsa-libs rpm.
> You need the alsa-utils rpm to get alsamixer so that you can
> unmute your soundcard.
and do we have a volunteer to go back over the last 20+
posts regarding ALSA sound under test-2.6.0 and summarize all
that into a nice, condensed recipe? i've seen enough 2.6.0
kernel today to last me a while.
then we just have to pick a new topic to beat to death.
ACPI, anyone?
rday
--
Rhl-beta-list mailing list
Rhl-beta-list(a)redhat.com
http://www.redhat.com/mailman/listinfo/rhl-beta-list
>
20 years, 9 months
Letting Ordinary Users Write To Disk Key
by Robert L Cochran
I have a 128 Mb disk key plugged into my test machine. Severn recognizes
it, and I've formatted and mounted the thing as '/mnt/dkey'. How can I
give an ordinary user (namely, me) write access to it?
Thanks
Bob Cochran
20 years, 9 months
Advanced Display parameters missing in severn
by Gerry Tool
In RHL9 the System Settings > Display dialog has an Advanced tab with a
DPI section and a Set DPI button that opens a sub-dialog that allows
manual setting of the Monitor width and height in whatever units one
specifies. This is very useful for matching the dimensions of a frame
in a word processor with the dimensions of a picture inserted from a
file that has the size determined by a program such as Gimp.
There is no such facility in the Display applet in severn. Is there
another way to set these parameters? If not, it seems a regression to
remove this facility from the new version of RHL.
Thanks.
Gerry
20 years, 9 months