9:47 a.m.
After doing a fresh "everything" install of FC4, I tried a 'yum
upgrade', and got these errors,
---> Package kernel.i686 0:2.6.14-1.1653_FC4 set to be installed
--> Running transaction check
Error: Unable to satisfy dependencies
Error: Package dlm-kernel needs /lib/modules/2.6.14-1.1653_FC4, this is
not available.
Error: Package cman-kernel needs /lib/modules/2.6.14-1.1653_FC4, this is
not available.
Error: Package GFS-kernel needs /lib/modules/2.6.14-1.1653_FC4, this is
not available.
Error: Package gnbd-kernel needs /lib/modules/2.6.14-1.1653_FC4, this is
not available.
This exact problem has been addressed here,
https://www.redhat.com/archives/fedora-list/2006-January/msg01530.html
and another long thread here,
https://www.redhat.com/archives/fedora-list/2005-October/msg03542.html
and, as it suggested, I just removed those packages - which I don't
think I need,
# yum remove dlm-kernel cman-kernel GFS-kernel gnbd-kernel
However, the upgrade didn't seem to finish because I still have a
2.6.11-1.1369_FC4 kernel, and I thought it was upgrading me to
0:2.6.14-1.1653_FC4, but stopped when these errors showed up. If I try
'yum upgrade' again after removing those, it eventually gets to these
same errors. (I also tried 'yum clean all' after the 'yum remove').
Do I need more than 'yum remove' to have it completely ignore these
packages next time I try to upgrade?
thanks,
Ken
9:55 a.m.
Ken Schutte wrote:
After doing a fresh "everything" install of FC4, I tried a
'yum
upgrade', and got these errors,
---> Package kernel.i686 0:2.6.14-1.1653_FC4 set to be installed
--> Running transaction check
Error: Unable to satisfy dependencies
Error: Package dlm-kernel needs /lib/modules/2.6.14-1.1653_FC4, this is
not available.
Error: Package cman-kernel needs /lib/modules/2.6.14-1.1653_FC4, this is
not available.
Error: Package GFS-kernel needs /lib/modules/2.6.14-1.1653_FC4, this is
not available.
Error: Package gnbd-kernel needs /lib/modules/2.6.14-1.1653_FC4, this is
not available.
This exact problem has been addressed here,
https://www.redhat.com/archives/fedora-list/2006-January/msg01530.html
and another long thread here,
https://www.redhat.com/archives/fedora-list/2005-October/msg03542.html
and, as it suggested, I just removed those packages - which I don't
think I need,
# yum remove dlm-kernel cman-kernel GFS-kernel gnbd-kernel
However, the upgrade didn't seem to finish because I still have a
2.6.11-1.1369_FC4 kernel, and I thought it was upgrading me to
0:2.6.14-1.1653_FC4, but stopped when these errors showed up. If I try
'yum upgrade' again after removing those, it eventually gets to these
same errors. (I also tried 'yum clean all' after the 'yum remove').
Do I need more than 'yum remove' to have it completely ignore these
packages next time I try to upgrade?
It looks like your "yum remove" didn't work. Which kernel packages are
actually still installed?
$ rpm -qa '*kernel*'
Paul.
9:59 a.m.
Paul Howarth wrote:
>
> Do I need more than 'yum remove' to have it completely ignore these
> packages next time I try to upgrade?
It looks like your "yum remove" didn't work. Which kernel packages are
actually still installed?
$ rpm -qa '*kernel*'
Immediately after the 'yum remove',
# rpm -qa 'kernel*'
kernel-2.6.11-1.1369_FC4
kernel-doc-2.6.11-1.1369_FC4
kernel-smp-devel-2.6.11-1.1369_FC4
kernel-smp-2.6.11-1.1369_FC4
kernel-devel-2.6.11-1.1369_FC4
10:01 a.m.
Ken Schutte wrote:
Paul Howarth wrote:
>>
>> Do I need more than 'yum remove' to have it completely ignore these
>> packages next time I try to upgrade?
>
>
>
> It looks like your "yum remove" didn't work. Which kernel packages are
> actually still installed?
>
> $ rpm -qa '*kernel*'
Immediately after the 'yum remove',
# rpm -qa 'kernel*'
kernel-2.6.11-1.1369_FC4
kernel-doc-2.6.11-1.1369_FC4
kernel-smp-devel-2.6.11-1.1369_FC4
kernel-smp-2.6.11-1.1369_FC4
kernel-devel-2.6.11-1.1369_FC4
That query won't pick up the offending modules. Note the asterisk
*before* "kernel".
Paul.
1:16 p.m.
Paul Howarth wrote:
>>
>> It looks like your "yum remove" didn't work. Which kernel packages
>> are actually still installed?
>>
>> $ rpm -qa '*kernel*'
>
>
>
> Immediately after the 'yum remove',
> # rpm -qa 'kernel*'
> kernel-2.6.11-1.1369_FC4
> kernel-doc-2.6.11-1.1369_FC4
> kernel-smp-devel-2.6.11-1.1369_FC4
> kernel-smp-2.6.11-1.1369_FC4
> kernel-devel-2.6.11-1.1369_FC4
That query won't pick up the offending modules. Note the asterisk
*before* "kernel".
Paul.
Oh, sorry, you're right. But, I'm not sure what I was doing wrong,
because actually now, I am not getting the errors about those packages.
However, some things (the 2.6.14 kernel) are still not installed. Now
that I look at it, it looks like it may be out of disk space. (189MB of
9.5GB available on /). I guess an "all packages" install was a
mistake... I guess I'll just re-install and choose my packages...
Thanks for the replies.
Ken
1:24 p.m.
On Fri, 2006-01-27 at 14:16 -0500, Ken Schutte wrote:
Paul Howarth wrote:
>>>
>>> It looks like your "yum remove" didn't work. Which kernel
packages
>>> are actually still installed?
>>>
>>> $ rpm -qa '*kernel*'
>>
>>
>>
>> Immediately after the 'yum remove',
>> # rpm -qa 'kernel*'
>> kernel-2.6.11-1.1369_FC4
>> kernel-doc-2.6.11-1.1369_FC4
>> kernel-smp-devel-2.6.11-1.1369_FC4
>> kernel-smp-2.6.11-1.1369_FC4
>> kernel-devel-2.6.11-1.1369_FC4
>
>
> That query won't pick up the offending modules. Note the asterisk
> *before* "kernel".
>
> Paul.
>
Oh, sorry, you're right. But, I'm not sure what I was doing wrong,
because actually now, I am not getting the errors about those packages.
However, some things (the 2.6.14 kernel) are still not installed. Now
that I look at it, it looks like it may be out of disk space. (189MB of
9.5GB available on /). I guess an "all packages" install was a
mistake... I guess I'll just re-install and choose my packages...
Try a "yum clean packages" first; it might free up quite a lot of disk
space if you've applied lots of updates.
Paul.
12:32 p.m.
New subject: slimserver and firewall
Hello All,
I'm trying to understand how the client/server interacts with ports and
firewalls by exploring a non-essential application on my home network.
The boxes are running FC4 and are connected to a router behind a DSL
modem.
The application is slimserver which streams mp3 files over a network to
a piece of hardware called a Squeezebox Network Music Player, which I
don't have. It can also steam the same files over the Internet to an
mp3 player like xmms running anywhere on the network, which is how I
want to use it.
The documentation says that slimserver (which I have installed on one
machine) must be reachable via port 9000. I program the slimserver
playlist (which can include Internet radio) at http://localhost:9000.
The clients (xmms) access the stream at
http://localhost:9000/stream.mp3, where "localhost" is now the name of
the box where slimserver is running. So far I can play music on the
server machine but not remotely.
What place(s) must I open port 9000? The router? Each of the client
machines? How safe is this -- or rather, maybe I should ask, what
precautions are advisable?
Thanks for the help. I hope my language isn't too awkward. Doing
seems to be the only way to really learn this stuff.
Jerry
12:52 p.m.
New subject: slimserver and firewall
What place(s) must I open port 9000? The router? Each of
the client
machines? How safe is this -- or rather, maybe I should ask, what
precautions are advisable?
Thanks for the help. I hope my language isn't too awkward. Doing
seems to be the only way to really learn this stuff.
Probably best to open this on your box only (unless off course you
want to run an Internet radio, which would mean opening the port on
the router aswell). The client machines mostly use other ports to
access slimserver, which means they establish a connection, something
which is almost always doable, you don't have to open ports on a
client to let it make connections. On the server box you can open the
port (presuming you only run iptables) as root:
# iptables -I INPUT -s 192.168.0.0/24 --dport 9000 -j ACCEPT
(change 192.168.0.0 to whatever your network is)
# iptables-save
(to save the changes on rebooting the box)
This will allow only people on your network to reach slimserver.
Opening a port to the network is not so unsafe, especially since there
is a server listening on that port. Only advice I could give is, make
sure that slimsrever stays up to date.
Hope, this helps
Bart
7:31 p.m.
New subject: slimserver and firewall
On Tue, 2006-01-31 at 19:52 +0100, Bart Couvreur wrote:
> What place(s) must I open port 9000? The router? Each
of the client
> machines? How safe is this -- or rather, maybe I should ask, what
> precautions are advisable?
> Thanks for the help. I hope my language isn't too awkward. Doing
> seems to be the only way to really learn this stuff.
>
Probably best to open this on your box only (unless off course you
want to run an Internet radio, which would mean opening the port on
the router aswell). The client machines mostly use other ports to
access slimserver, which means they establish a connection, something
which is almost always doable, you don't have to open ports on a
client to let it make connections. On the server box you can open the
port (presuming you only run iptables) as root:
# iptables -I INPUT -s 192.168.0.0/24 --dport 9000 -j ACCEPT
(change 192.168.0.0 to whatever your network is)
# iptables-save
(to save the changes on rebooting the box)
This will allow only people on your network to reach slimserver.
Opening a port to the network is not so unsafe, especially since there
is a server listening on that port. Only advice I could give is, make
sure that slimsrever stays up to date.
I'm only interested in streaming audio over the LAN (for the time being
anyway.)
The slimserver is on 192.168.1.11 behind default gateway 192.168.1.1
(the router). The router is behind LAN address 192.168.0.1 (the DSL
modem). I've been assuming that 192.168.1.0/24 is the right form for my
network source IP address here.
(1) So why isn't this working?
root@PuteA Sat Feb 04 16:52:31
[240] ~ $ iptables -I INPUT -s 192.168.1.0/24 --dport 9000 -j ACCEPT
iptables v1.3.0: Unknown arg `--dport'
(2) Also, I've noticed that the box on which I've installed slimserver
now has another user (which I did not add!) called "slimserver" with a
home directory of /usr/local/slimserver. Under "User Properties -->
Account Info" the "local password is locked" box is checked.
Thanks for the help on this!
10:09 a.m.
New subject: slimserver and firewall
(1) So why isn't this working?
root@PuteA Sat Feb 04 16:52:31
[240] ~ $ iptables -I INPUT -s 192.168.1.0/24 --dport 9000 -j ACCEPT
iptables v1.3.0: Unknown arg `--dport'
Sorry forgot something in the line there, it should be:
# iptables -I INPUT -s 192.168.0.0/24 -p tcp --dport 9000 -j ACCEPT
Don't quite rember if slimserver needs UDP aswell, if so also enter:
# iptables -I INPUT -s 192.168.0.0/24 -p udp --dport 9000 -j ACCEP
(2) Also, I've noticed that the box on which I've installed
slimserver
now has another user (which I did not add!) called "slimserver" with a
home directory of /usr/local/slimserver. Under "User Properties -->
Account Info" the "local password is locked" box is checked.
This is a default setting, meant to run slimserver as a seperate user
other than root, for security reasons. You'd better keep it this way
so slimserver can't access the whole system.
Ciao,
Bart
6:20 p.m.
New subject: slimserver and firewall
On Sun, 2006-02-05 at 17:09 +0100, Bart Couvreur wrote:
> (1) So why isn't this working?
>
> root@PuteA Sat Feb 04 16:52:31
> [240] ~ $ iptables -I INPUT -s 192.168.1.0/24 --dport 9000 -j ACCEPT
> iptables v1.3.0: Unknown arg `--dport'
Sorry forgot something in the line there, it should be:
# iptables -I INPUT -s 192.168.0.0/24 -p tcp --dport 9000 -j ACCEPT
Don't quite rember if slimserver needs UDP aswell, if so also enter:
# iptables -I INPUT -s 192.168.0.0/24 -p udp --dport 9000 -j ACCEP
OK Bart, I'm almost there...
root@PuteA Mon Feb 06 16:06:57
[267] /home/magnusg $ iptables -I INPUT -s 192.168.1.0/24 -p tcp --dport
9000 -j ACCEPT
root@PuteA Mon Feb 06 16:11:48
[268] /home/magnusg $ iptables -I INPUT -s 192.168.1.0/24 -p udp --dport
9000 -j ACCEPT
root@PuteA Mon Feb 06 16:12:02
[269] /home/magnusg $ iptables -L
Chain FORWARD (policy ACCEPT)
target prot opt source destination
RH-Firewall-1-INPUT all -- anywhere anywhere
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT udp -- 192.168.1.0/24 anywhere udp
dpt:9000
ACCEPT tcp -- 192.168.1.0/24 anywhere tcp
dpt:9000
RH-Firewall-1-INPUT all -- anywhere anywhere (etc.)
At this point I'm able to access slimserver remotely, either via the
browser (http://192.168.1.11:9000) or via an audio player like xmms
(http://192.168.1.11:9000/stream.mp3). But when I reboot, the iptables
configuration goes back to what it was before. So I need to save these
changes somehow.
Entering "iptables-save" before rebooting doesn't work; "iptables-save
-c" as it says in the "Red Hat Linux Bible" doesn't work either.
What's
the right command here, in FC4?
Thanks again for the help.
Jerry
10:08 p.m.
New subject: slimserver and firewall
Gerhard Magnus wrote:
root@PuteA Mon Feb 06 16:11:48
[268] /home/magnusg $ iptables -I INPUT -s 192.168.1.0/24 -p udp --dport
9000 -j ACCEPT
Entering "iptables-save" before rebooting doesn't work; "iptables-save
-c" as it says in the "Red Hat Linux Bible" doesn't work either.
What's
the right command here, in FC4?
Thanks again for the help.
Jerry
You have choices. First of all iptables-save does work, but it writes
by default to stdout, not to /etc/sysconfig/iptables which is the rule
file loaded by the iptables service upon startup. So you could redirect
output from the command to that file:
'iptables-save >/etc/sysconfig/iptables'
Second you could tell the iptables service script to save it for you:
'service iptables save'
Or third, you could edit /etc/sysconfig/iptables yourself to insert the
lines
# Permit access to slimserver
-A RH-Firewall-1-INPUT -s 192.168.1.0/24 -p udp --dport 9000 -j ACCEPT
right below the line:
-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
The latter method will preserve comments in that file, while the first
two methods will destroy them.
Chris
--
"Spend less! Do more! Go Open Source..." -- Dirigo.net
Chris Johnson, RHCE #804005699817957
7:40 a.m.
New subject: slimserver and firewall
On Mon, 2006-02-06 at 23:08 -0500, Christopher K. Johnson wrote:
Gerhard Magnus wrote:
>root@PuteA Mon Feb 06 16:11:48
>[268] /home/magnusg $ iptables -I INPUT -s 192.168.1.0/24 -p udp --dport
>9000 -j ACCEPT
>
>Entering "iptables-save" before rebooting doesn't work;
"iptables-save
>-c" as it says in the "Red Hat Linux Bible" doesn't work either.
What's
>the right command here, in FC4?
"service iptables save"
This does work to save the tables to /etc/sysconfig/iptables for me.
>
>Thanks again for the help.
>Jerry
>
>
>
You have choices. First of all iptables-save does work, but it writes
by default to stdout, not to /etc/sysconfig/iptables which is the rule
file loaded by the iptables service upon startup. So you could redirect
output from the command to that file:
'iptables-save >/etc/sysconfig/iptables'
Second you could tell the iptables service script to save it for you:
'service iptables save'
Or third, you could edit /etc/sysconfig/iptables yourself to insert the
lines
# Permit access to slimserver
-A RH-Firewall-1-INPUT -s 192.168.1.0/24 -p udp --dport 9000 -j ACCEPT
right below the line:
-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
The latter method will preserve comments in that file, while the first
two methods will destroy them.
Chris
--
"Spend less! Do more! Go Open Source..." -- Dirigo.net
Chris Johnson, RHCE #804005699817957
1:05 p.m.
New subject: slimserver and firewall
On Tuesday 31 January 2006 12:32, Gerhard Magnus wrote:
Hello All,
I'm trying to understand how the client/server interacts with
ports and firewalls by exploring a non-essential application on
my home network. The boxes are running FC4 and are connected to a
router behind a DSL modem.
The application is slimserver which streams mp3 files over a
network to a piece of hardware called a Squeezebox Network Music
Player, which I don't have. It can also steam the same files
over the Internet to an mp3 player like xmms running anywhere on
the network, which is how I want to use it.
The documentation says that slimserver (which I have installed
on one machine) must be reachable via port 9000. I program the
slimserver playlist (which can include Internet radio) at
http://localhost:9000. The clients (xmms) access the stream at
http://localhost:9000/stream.mp3, where "localhost" is now the
name of the box where slimserver is running. So far I can play
music on the server machine but not remotely.
"localhost" is somewhat synonymous with "the machine you're sitting
in front of" so if you're trying to connect using "localhost" the
only machine that will work is "the one you're sitting in front
of". To connect over the network you'll have to know the IP
address of the server; i.e. http://192.168.1.1:9000/stream.mp3.
For this to work, you'll have to make sure that your machine running
the slimserver program has port 9000 available to the other
machines on your network. A quick test is to just turn off your
iptables firewall if you have it running; i.e.
"/etc/init.d/iptables stop" from a console prompt on the machine
with the slimserver program. If you want to re-enable a firewall
there are several applications that will make configuring a
firewall easier; e.g 'webmin'.
For machines on the Internet to connect to your slimserver machine
you'll have to configure your router to forward port 9000 to your
machine running the slimserver program. How this is done will vary
on the kind of router you are using.
Setting this up may require you to learn how to troubleshoot network
connections. Learning to use ping. netstat, tcpdump, iptraf, nmap,
etc. won't be a waste of time.
Regards, Mike Klinke
5:36 a.m.
On Fri, 2006-01-27 at 14:16 -0500, Ken Schutte wrote:
I guess an "all packages" install was a mistake...
It can be. I did that once, to try and avoid having to solve
dependencies all over the place, myself, later on when I wanted to try
out something new.
What happens is even more dependencies need solving anytime you do an
update, which involves many megs of updates to stuff you don't use, nor
even knew you had.
With YUM, etc., it's easier to install things you want to try later, and
solve the extra dependencies there and then.
--
Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.
3:25 p.m.
On Fri, Jan 27, 2006 at 10:59:47AM -0500, Ken Schutte wrote:
Paul Howarth wrote:
>>
>>Do I need more than 'yum remove' to have it completely ignore these
>>packages next time I try to upgrade?
>
>
>It looks like your "yum remove" didn't work. Which kernel packages are
>actually still installed?
>
>$ rpm -qa '*kernel*'
Immediately after the 'yum remove',
# rpm -qa 'kernel*'
kernel-2.6.11-1.1369_FC4
kernel-doc-2.6.11-1.1369_FC4
kernel-smp-devel-2.6.11-1.1369_FC4
kernel-smp-2.6.11-1.1369_FC4
kernel-devel-2.6.11-1.1369_FC4
yum --exclude=*kernel*" update
will not update any rpm with the string kernel in its name.
--
=======================================================================
It's all right letting yourself go as long as you can let yourself back.
-- Mick Jagger
-------------------------------------------
Aaron Konstam
Computer Science
Trinity University
telephone: (210)-999-7484
6646
days inactive
6657
days old
15 comments
9 participants
participants (9)
-
akonstam＠trinity.edu -
Bart Couvreur -
Christopher K. Johnson -
Gerhard Magnus -
Jeff Vian -
Ken Schutte -
Mike Klinke -
Paul Howarth -
Tim