SEO

I need a static ip for my box. I've made sure I am trying to
use an address not being passed out from my Linksys WRT54G router, so not
1, nor 102 thru 110. I've read the related section in the Slackbook on the
install cd's (5.3.3 /etc/rc.d/rc.inet1.conf). I've tried making this work
two ways and each fails. The second way that failed was to use
'netconfig' which seem to produce the same config I did manually. Here--
the first way that failed--are some of the different options I have
tried putting in the rc.inet1.conf file:

a)
# Primary network interface card (eth0) IPADDR[0]="192.168.1.101"
NETMASK[0]=""
USE_DHCP[0]=""
DHCP_HOSTNAME[0]=""

GATEWAY=""
b)
# Primary network interface card (eth0) IPADDR[0]="192.168.1.101"
NETMASK[0]="255.255.255.0"
USE_DHCP[0]=""
DHCP_HOSTNAME[0]=""

GATEWAY="192.168.1.1"

a) or b) above should both work fine, I would think. I
assume that the section in rc.inet1 is fine where...
<code>
if [ "${USE_DHCP[$i]}" = "yes" ]; then # use DHCP to bring interface up
...
else # bring up interface using a static IP address
if [ ! "${IPADDR[$i]}" = "" ]; then # skip unconfigured interfaces
# Determine broadcast address from the IP address and netmask:
BROADCAST[$i]=`/bin/ipmask ${NETMASK[$i]} ${IPADDR[$i]}|cut -f1
-d' '` # Set up the network card:
echo "/etc/rc.d/rc.inet1: /sbin/ifconfig ${1} ${IPADDR[$i]}
broadcast ${BROADCAST[$i]} netmask ${NETMASK[$i]}" | $LOGGER
/sbin/ifconfig ${1} ${IPADDR[$i]} broadcast ${BROADCAST[$i]}
netmask ${NETMASK[$i]}
else
if [ "$DEBUG_ETH_UP" = "yes" ]; then
echo "/etc/rc.d/rc.inet1: ${1} interface is not configured in
/etc/rc.d/rc.inet1.conf" | $LOGGER
fi
fi
fi
</code>

After restarting the machine I have no working internet. I have verified
that the /etc/dhcpc/dhcpcd-eth0.info file looks correct, and used ifconfig
to see my ip. Maybe something isn't getting started? Is
there a simplier way I can stop and start the associated services without
having to do a reboot s after each change I make. I noticed and tried
'./rc.inet1 restart', and also the conbo of './rc.inet1 stop' './rc.inetd
restart' followed by './rc.inet1 start'. I think after one of the reboots
I issued './rc.inetd restart' and there was a line that something wasn't
started before it continued on (sorry I don't have that). I hope in all
this something stands out to you experts. Let me know and I'll give
it a whirl.

Thanks a lot for your time,
Aaron

On Sun, 25 Sep 2005 07:21:35 +0000, aaronl wrote:

> # Primary network interface card (eth0) IPADDR[0]="192.168.1.101"

This was just a format typo in message, my real file is on two lines...
# Config information for eth0:
IPADDR[0]="192.168.1.101"

thanks again,
aaron

aaronl <ghost@deepspace.org> wrote:
> I need a static ip for my box.

My guess is that you got success so far...

> I've read the related section in the Slackbook on the install cd's
> (5.3.3 /etc/rc.d/rc.inet1.conf). I've tried making this work two ways
> and each fails. The second way that failed was to use 'netconfig' which
> seem to produce the same config I did manually.

> a)
> # Primary network interface card (eth0) IPADDR[0]="192.168.1.101"
> NETMASK[0]=""
> USE_DHCP[0]=""
> DHCP_HOSTNAME[0]=""
>
> GATEWAY=""

That configuration is lacking a netmask, I think it then will default to
the netmask 255.0.0.0 which probably is wrong for your small home network.
Also, it is lacking a gateway. Without a gateway your machine will not
know how to find its way out to the internet.

> b)
> # Primary network interface card (eth0) IPADDR[0]="192.168.1.101"
> NETMASK[0]="255.255.255.0"
> USE_DHCP[0]=""
> DHCP_HOSTNAME[0]=""
>
> GATEWAY="192.168.1.1"

That configuration seems good, assuming that your netmask is right.

> After restarting the machine I have no working internet.

What do you mean by "no working internet"? Are you unable to surf to a
place like "www.google.com". That would probably be because you didn't
configure which DNS server to use. DNS servers are used to translate a
name like www.google.com to an ip-address like 66.249.93.99.

> I have verified that the /etc/dhcpc/dhcpcd-eth0.info file looks correct

Why would that file look correct and why would you care? As you now are
using a static IP adress you are not using dhcp.

> and used ifconfig to see my ip.

That is good, then you did succeed in configuring a static IP address for
you machine. The next step would be to see you your machine is able to
ping its own IP address. After that you should test if it is able to ping
the IP address of your router. Then you could try and see if you are able
to ping an ip address out there, like 66.249.93.99.

> Maybe something isn't getting started?

My guess is that you did forget to tell netconfig about your DNS servers
(or rather the DNS servers of your ISP). Those servers should have been
placed by netconfig in the file /etc/resolv.conf. After editing
/etc/resolv.conf you do not have to restart anything. If you are able to
ping a known IP address out on the internet but unable to ping a known
hostname this is most likely the case. If you are unable to ping your own
router you probably have something misconfigured, but it could also be the
router which has some firewall setting refusing to answer ping.

> I noticed and tried './rc.inet1 restart'

That is usually the way to make a new configuration take place without
having to reboot the machine.

> I think after one of the reboots I issued './rc.inetd restart' and there
> was a line that something wasn't started before it continued on (sorry I
> don't have that).

I can't tell if the error message is critical without having seen it.

--
The address in the header is only to prevent spam. My real address is:
hc7(at)uthyres.com Examples of addresses which go to spammers:
root@variousus.net info@k-soft.se info@k-software.biz root@localhost

aaronl wrote:

>I need a static ip for my box. I've made sure I am trying to
>use an address not being passed out from my Linksys WRT54G router, so not
>1, nor 102 thru 110. I've read the related section in the Slackbook on the
>install cd's (5.3.3 /etc/rc.d/rc.inet1.conf). I've tried making this work
>two ways and each fails. The second way that failed was to use
>'netconfig' which seem to produce the same config I did manually. Here--
>the first way that failed--are some of the different options I have
>tried putting in the rc.inet1.conf file:
>
>
>
>
Give something like this a try:

# Config information for eth0:
IPADDR[0]="192.168.1.10"
NETMASK[0]="255.255.255.0"
USE_DHCP[0]=""
DHCP_HOSTNAME[0]=""

...

# Default gateway IP address:
GATEWAY="192.168.1.1"

That sets your machine address to 192.168.1.10 (I have three machines,
all static, with addresses 192.168.1.10, 192.168.1.20, 192.168.1.30 and
a non-static H-P printer that connects as 192.168.1.100). All that works
just fine with a Linksys router (a BEFSR41, but what the heck).

On this machine, /etc/hosts looks like:

# For loopbacking.
127.0.0.1 localhost
192.168.1.10 fubar.com fubar
192.168.1.20 snafu.com snafu
...

and /etc/resolv.conf contains the address of the nameserver specified by
my ISP like this:

search com
nameserver nnn.nnn.nnn.nnn

(where nnn.nnn.nnn.nnn is the address).

In the Linksys the Setup screen has the default values

192.168.1.1 (Device IP Address)
255.255.255.0 (Subnet Mask)

and my ISP uses PPPoE. My login name and password are entered in the
User Name and Password fields.

Hope this helps.

On Sun, 25 Sep 2005 12:43:46 +0200, Henrik Carlqvist wrote:

> My guess is that you did forget to tell netconfig about your DNS servers
> (or rather the DNS servers of your ISP). Those servers should have been
> placed by netconfig in the file /etc/resolv.conf. After editing
> /etc/resolv.conf you do not have to restart anything.

You guys deduced correctly--good job. It is working now.
/etc/resolv.conf needed the following added to point to my router--which
is configured to handle the translation:
<addition> nameserver 192.168.1.1 </addition>

My assigned ip was getting set in earlier attempts and I could ping the
outside address you supplied, but could not get a website to come up, so
I stuck that ip in a browser and bingo--google came up. I was happy then,
becuase I knew you were right.

I also tweaked my host file to add the hardcoded ip. Was this necessary?
And should I have commented out the loopback line associated with my
server name as shown below?:
<file>
# For loopbacking.
127.0.0.1 localhost
#127.0.0.1 darkstar.deepspace.org darkstar
192.168.1.69 darkstar.deepspace.org darkstar
</file>

One last thing. Early in the game I thought my firewall might
be part of the problem. I can to use the iptables command to add and
drop rules, but how does one stop the entire rc.firewall script without
having to 'chmod -x rc.firewall' and reboot? Would it be
'start|stop|restart' code added to the rc.firewall script itself or to
other script that calls it, rc.inet2 or something. Can I get the process
from 'ps' somehow and 'kill' it that way? My firewall itself is pretty
basic--something I grabbed off the internet many moons ago. For
convienence I wrote a simple shell script to add and drop global
permissions to allow friends in from time to time, but I've always wanted
to know how to stop and restart the whole darn thing when debugging
problems like the one in this thread:

(note: Pan's wrap warnings and 'rewrap' mess up posting format on some
lines below)

<firewall>
#!/bin/bash
#
# Basic script to keep the nasties out of slack

# First we make the default policy to drop everything
iptables -P INPUT DROP
iptables -P FORWARD DROP

# Allow established connections and programs that use loopback
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -s 127.0.0.0/8 -d 127.0.0.0/8 -i lo -j ACCEPT

# Allow lan users to connect to Apache iptables -t filter -A INPUT -p tcp
-s 192.168.1.0/24 -i eth0 --dport 80 -j ACCEPT

# allow ssh and apache connections from work
iptables -t filter -A INPUT -p tcp -s ###.###.##.0/24 -i eth0 --dport 22 -j
ACCEPT
iptables -t filter -A INPUT -p tcp -s ###.###.##.0/24 -i eth0 --dport 80 -j
ACCEPT

#end script
</firewall>

comments welcome!

aaron

aaronl <ghost@deepspace.org> wrote:
> I also tweaked my host file to add the hardcoded ip. Was this necessary?

Yes, it is really a good idea to have it there. Otherwise some programs
might behave more or less bad. Sendmail is known to make a pause of 2
minutes during boot unless it is able to find an ip adress for its
hostname.

> And should I have commented out the loopback line associated with my
> server name as shown below?:

The loopback 127.0.0.1 should only be pointing to localhost.

> <file>
> # For loopbacking.
> 127.0.0.1 localhost
> #127.0.0.1 darkstar.deepspace.org darkstar
> 192.168.1.69 darkstar.deepspace.org darkstar
> </file>

That looks good, 127.0.0.1 points to localhost and 192.168.1.69 points to
your hostname.

> One last thing. Early in the game I thought my firewall might be part of
> the problem. I can to use the iptables command to add and drop rules,
> but how does one stop the entire rc.firewall script without having to
> 'chmod -x rc.firewall' and reboot? Would it be 'start|stop|restart'
> code added to the rc.firewall script itself or to other script that
> calls it, rc.inet2 or something.

If you want to stop your firewall, then you would want to have support for
a stop commando to your rc.firewall. You probably don't want to stop
rc.inet2 as that would stop other things also like nfs mounts and the
system logger. However, rc.inet2 does not support a stop command, at least
not in my Slackware 9.1 system. On the other hand I don't have any
rc.firewall either.

regards Henrik
--
The address in the header is only to prevent spam. My real address is:
hc7(at)uthyres.com Examples of addresses which go to spammers:
root@variousus.net info@k-soft.se info@k-software.biz root@localhost

aaronl wrote:
> On Sun, 25 Sep 2005 12:43:46 +0200, Henrik Carlqvist wrote:
>
> > [ snip ]
[ snip ]
> but how does one stop the entire rc.firewall script without
> having to 'chmod -x rc.firewall' and reboot? Would it be
> 'start|stop|restart' code added to the rc.firewall script itself or to
> other script that calls it, rc.inet2 or something. Can I get the process
> from 'ps' somehow and 'kill' it that way? My firewall itself is pretty
> basic--something I grabbed off the internet many moons ago.

No answer according to yours.

But I can share that the fireHol firewall supports: start | stop |
status

(may can look at firewall script from thereof for ideas?)

And that I snitched a copy of fireHol's firewall script and also the
firehol.conf from my Debian box. Put said firewall script as
/etc/rc.d/rc.firewall and said .conf as /etc/firehol/firehol.conf on
Slackware 10.1 and then made a sym link in/of /usr/local/bin/firehol
which points to /etc/rc.d/rc.firewall

Thus when Slack boots can see on screen three informative lines to the
effect of fireHol is activating/activated/fully_activated

iptables -L

lists over 41 firewall rules. It appears to be reasonably stealthed
(not been broke into) cannot even ping at all either out or from
another box to this one.

firehol stop

as root totally gets rid of firewall where

iptables -L

lists no rules

firehol start

puts it back as before.

I've a yum repository on Slack box that I ocasional LAN only use. I
dis connect from internet (56K dialup), start Apache -- and . . .

Slack box is not even found at all on LAN until: firehol stop

then do yum repo business on LAN. then off Apache and firehol start

(I got it from your basic firewall script how to let in a local LAN
box) and I'll try it -- should be easier than my method so far.

I keep evolving in how I do things as I learn more and more.

fireHol (installed on Slackware rather than snitch a copy of stuff)
perhaps isn't a fit for Slackware? (google etc. for: "slackware
firehol" turns up nothing) (on a Deb box, just: apt-get install
firehol).

--
Al_Cu B C N U

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In alt.os.linux.slackware, aaronl dared to utter,
> One last thing. Early in the game I thought my firewall might
> be part of the problem. I can to use the iptables command to add and
> drop rules, but how does one stop the entire rc.firewall script without
> having to 'chmod -x rc.firewall' and reboot?

# man iptables
# /sbin/iptables -F

- --
It is better to hear the rebuke of the wise,
Than for a man to hear the song of fools.
Ecclesiastes 7:5
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.7 (GNU/Linux)

iD8DBQFDN004zLTO1iU1uO4RAmLXAKCjRFTlRw134loken/qxqq22TOnFwCeLy6w
VwTqojOOR1QRB/VzdtINXoA=
=o649
-----END PGP SIGNATURE-----

On Sun, 25 Sep 2005 20:22:46 -0500,
+Alan Hicks+ <alan@lizella.netWORK> wrote:
> In alt.os.linux.slackware, aaronl dared to utter,
>
>> One last thing. Early in the game I thought my firewall might
>> be part of the problem. I can to use the iptables command to
>> add and drop rules, but how does one stop the entire
>> rc.firewall script without having to 'chmod -x rc.firewall' and
>> reboot?
>
> # man iptables
> # /sbin/iptables -F

I don't think this is quite what the OP was asking for, at least
it doesn't do the same thing in my slack 9.1 install.

Booting without rc.firewall executable leaves the system open,
with the three basic chains (INPUT, FORWARD, and OUTPUT) all
defined as ACCEPT.

Calling iptables with the "-F" switch flushes all rules and leaves
these chains in their default state of DROP, and no packets will
be passed.

I think one way to accomplish what the OP wants would be to write
a short script that flushes all rules and also sets the default
policy to ACCEPT.

Note to the OP, you didn't indicate which version of Slackware you
are using, but iptables is in /usr/sbin/ with 9.1.

--
Theodore (Ted) Heise <theo@heise.nu> Bloomington, IN, USA

On Wed, 28 Sep 2005 23:22:03 +0000, Theodore Heise wrote:

>>> One last thing. Early in the game I thought my firewall might
>>> be part of the problem. I can use the iptables command to
>>> add and drop rules, but how does one stop the entire
>>> rc.firewall script without having to 'chmod -x rc.firewall' and
>>> reboot?
>>
>> # man iptables
>> # /sbin/iptables -F
>
> I don't think this is quite what the OP was asking for, at least
> it doesn't do the same thing in my slack 9.1 install.
>
> Booting without rc.firewall executable leaves the system open,
> with the three basic chains (INPUT, FORWARD, and OUTPUT) all
> defined as ACCEPT.
>
> Calling iptables with the "-F" switch flushes all rules and leaves
> these chains in their default state of DROP, and no packets will
> be passed.
>
> I think one way to accomplish what the OP wants would be to write
> a short script that flushes all rules and also sets the default
> policy to ACCEPT.

Yep.

What you are thinking is correct, although the -F is nice too.

Unformtunely I have been working 27/7 this week and am dog tired (salary
jobs can suck!). 'Streching' an employee is not an endlessly good thing;
it is a word that to me now means 'run like hell'.

Anyhow, I'll have time to put something together this weekend; the
comments here have helped me understand what I need to do. I'll post the
newer script back here to verify that it isn't some crazy approach I make.

For now, m u s t s l e e p.

Thanks
Aaron