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
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.
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
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.
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
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.
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.
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.
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
What place(s) must I open port 9000? The router? Each of the clientmachines? 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
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
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 clientmachines? 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!
(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
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
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
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
-
akonstam＠trinity.edu -
Bart Couvreur -
Christopher K. Johnson -
Gerhard Magnus -
Jeff Vian -
Ken Schutte -
Mike Klinke -
Paul Howarth -
Tim