Re: [leaf-devel] remote package install
Eric said: > At least not for what I want to do, you are aiming a lot higher. My goal > would be to provide a non NIC dependent solution for loading a small > storage device (floppy) and still have the flexibility to load any > number of packages (memory limitations forbid). Actually a very simple > goal. I believe your approach would cover all my needs but as said, you > are aiming a lot higher. I would like to implement it as a snap in to > the existing Bering distribution and IMHO this forbids any tampering > with linuxrc. ...so you also would need DHCP/BOOTP server in the "location" where you place your leaf firewall then - or? I don't know to much about the leaf startup process (yet) to thinker with all the scripts however, it seams to me, that it should not be that hard for a person that is somewhat more experienced. As said before - I'll be more than happy to be a tester proveded we have a "propper" remote solutions built. Best regards Jorn --- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] [ leaf-Bugs-758334 ] Problems at partial backup etc.lrp
Bugs item #758334, was opened at 2003-06-21 11:58
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=113751&aid=758334&group_id=13751
Category: Release/Branch: Bering
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Eric Wolzak (ericw)
Assigned to: Eric Wolzak (ericw)
Summary: Problems at partial backup etc.lrp
Initial Comment:
In Bering and probably dachstein also there is a problem
if a partial backup of etc.lrp is used without setting
the /var/lib/lrpkg/etc.local file
In this cases the content of /var/lib/lrpkg/pkgname.*
and the to this package belonging files of /etc/* are
used.
The selection is done by the routine mk_inc_part
from /usr/sbin/lrcfg.back.script
The selection routine
sed -n -e \:etc/:p -e \:${LRPKG#/}:p $PKGLIST
>$INCLUDE
looks for all files in the package list that contains etc/
The package description for etc contains however etc
without slash. So the whole etc branch is excluded. And
the partial backup useless.
Solutions in a follow-up
Eric
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=113751&aid=758334&group_id=13751
---
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
___
leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] remote package install
At 12:32 AM 6/21/03 +0200, Erich Titl wrote: >>Any comments on why you wouldn't suggest rewritting linuxrc? > >For 2 reasons > >1) the existing linuxrc works for the actual LEAF releases and appears to >be reliable >2) laziness, I do not believe it is necessary :-) > >At least not for what I want to do, you are aiming a lot higher. My goal >would be to provide a non NIC dependent solution for loading a small >storage device (floppy) and still have the flexibility to load any number >of packages (memory limitations forbid). Actually a very simple goal. I >believe your approach would cover all my needs but as said, you are aiming >a lot higher. I would like to implement it as a snap in to the existing >Bering distribution and IMHO this forbids any tampering with linuxrc. > >Nevertheless your aproach is very interesting, keep me posted please. Having messed around with linuxrc a long time ago, I think this could be done as an add-in module that is executed after the network is up. 1) linuxrc unpacks all modules on the boot medium and runs init. 2) In due time the packages' init.d script is run. 3) It makes a list of all init scripts in /etc/init.d. 4) It downloads and extracts the additional packages listed in its config file. 5) Then it makes a new list of the scripts in /etc/init.d and executes any that were not there previously. The scripts would not be linked into the run level directories. linuxrc creates those based off of the variable RCDLINK so init would not execute any added scripts. JamesS --- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] remote package install
Jorn Jørn Eriksen wrote the following at 14:54 21.06.2003: Eric said: > At least not for what I want to do, you are aiming a lot higher. My goal > would be to provide a non NIC dependent solution for loading a small > storage device (floppy) and still have the flexibility to load any > number of packages (memory limitations forbid). Actually a very simple > goal. I believe your approach would cover all my needs but as said, you > are aiming a lot higher. I would like to implement it as a snap in to > the existing Bering distribution and IMHO this forbids any tampering > with linuxrc. ...so you also would need DHCP/BOOTP server in the "location" where you place your leaf firewall then - or? No, what I am thinking of is to add a init script which would be executed just after the network is initialised. This is some time after linuxrc is executed and has passed control to init. This init script can already build on a complete linux system and use it to download more software and integrate it to the system. It then switches init to another level and passes control to whatever is executed on that level cheers Erich THINK Püntenstrasse 39 8143 Stallikon mailto:[EMAIL PROTECTED] PGP Fingerprint: BC9A 25BC 3954 3BC8 C024 8D8A B7D4 FF9D 05B8 0A16 --- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] remote package install
James JamesSturdevant wrote the following at 15:47 21.06.2003: At 12:32 AM 6/21/03 +0200, Erich Titl wrote: >>Any comments on why you wouldn't suggest rewritting linuxrc? > >For 2 reasons > >1) the existing linuxrc works for the actual LEAF releases and appears to >be reliable >2) laziness, I do not believe it is necessary :-) > >At least not for what I want to do, you are aiming a lot higher. My goal >would be to provide a non NIC dependent solution for loading a small >storage device (floppy) and still have the flexibility to load any number >of packages (memory limitations forbid). Actually a very simple goal. I >believe your approach would cover all my needs but as said, you are aiming >a lot higher. I would like to implement it as a snap in to the existing >Bering distribution and IMHO this forbids any tampering with linuxrc. > >Nevertheless your aproach is very interesting, keep me posted please. Having messed around with linuxrc a long time ago, I think this could be done as an add-in module that is executed after the network is up. 1) linuxrc unpacks all modules on the boot medium and runs init. 2) In due time the packages' init.d script is run. 3) It makes a list of all init scripts in /etc/init.d. 4) It downloads and extracts the additional packages listed in its config file. 5) Then it makes a new list of the scripts in /etc/init.d and executes any that were not there previously. The scripts would not be linked into the run level directories. linuxrc creates those based off of the variable RCDLINK so init would not execute any added scripts. This is more or less what I want to do, but linuxrc plays no role here, I believe the new links in the init directories are done by update-rc.d and this should be very easy to use. Now if we switch to another run-level init takes over responsibility to execute everything needed by the run-level switch, done. cheers Erich THINK Püntenstrasse 39 8143 Stallikon mailto:[EMAIL PROTECTED] PGP Fingerprint: BC9A 25BC 3954 3BC8 C024 8D8A B7D4 FF9D 05B8 0A16 --- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] VLAN with vlan.lrp and bridge.lrp
Hi, good morning:
I am having some problems trying to set a vlan with
the Bering rc4 distribution. I going to explain what I
did it and how, to see if anyone can find the problem
or the mistake, because I think I am following the
documentation pretty good.
Here, this is a draw of what I am trying to set
---
- PC1 -
---
- eth0 IP 192.168.1.123
-
-
- eth1 IP 192.168.1.1
eth2 192.168.2.1 ---
- Bridge A - -- PC3 -
---
- eth0 IP 10.0.1.1 eth0 IP 192.168.2.3
-
-
- eth0 IP 10.0.1.2
eth2 192.168.2.2 ---
- Bridge B PC4 -
---
- eth1 IP 192.168.1.2eth0 IP 192.168.2.4
-
-
- eth0 IP 192.168.1.129
---
- PC2 -
---
BridgeA and BridgeB are running under Bering rc4 V1.2
with vlan.lrp bridge.lrp and 8021q.o and bridge.o
First I am gonna describe the situation of the
project. I have to computers, we will call them
BridgeA and BridgeB, which I wanna run as bridges.
Each computer has 3 Ethernet NICs. To apply vlan
support to the bridgeA and bridgeB I install in each
one the package vlan.lrp (wich provides the command
vconfig) and the module 8021q.o. Them to support the
bridge funcionality I install the the bridge.lrp
package and the bridge.o module.
them in each of these computers I do this:
First I assign an IP address to each NIC
BridgeA
eth0 10.0.1.1
eth1 192.168.1.1
eth2 192.168.2.1
and I set them up with the command Ifconfig
Ifconfig eth0 up
Ifconfig eth1 up
Ifconfig eth2 up
(To do this I had to install netutils.lrp because ifup
didn´t seem to work)
so I did the same in bridgeB
eth0 10.0.1.2
eth1 192.168.1.2
eth2 192.168.2.2
and I set them up with ifconfig again.
So now in each of the briges I create the Vlans
vconfig add eth0 10
vconfig add eth0 20
vconfig add eth1 10
vconfig add eth2 20
so now I have the interfaces
eth0.10 eth0.20 eth1.10 and eth2.20
so I set them up again with ifconfig like
ifconfig eth1.10 up
So now I only have to create the bridge
brctl addbr Orense
brctl addif Orense eth0.10
brctl addif Orense eth0.20
brctl addif Orense eth1.10
brctl addif Orense eth2.20
and I set the bridge up
Ifconfig Orense up
(as you can see I use the interfaces eth0 of each
bridge to connect them in a backbone between the two
machines)
so then conected to the eth1 of the bridgeA I have a
computer with a NIC that has an IP address
192.168.1.123 and conected to the eth1 of the bridgeB
I
have another NIC with 192.168.1.129.
As I see it has to work, doesn´t it? but If I do a
ping from 192.168.1.123 to 192.168.1.129 I can´t see
the other side. I only can reach the machine I am
conected to (because the IP address) but not using the
bridge and VLAN technology.
It is the same for the PC´s in the VLAN ID 20 PC3 and
PC4.
Can anyone tell me why or what I did wrong?
It works if I do the bridge with the phisical
interfaces eth0,eth1,eth2
Bridge Orense
eth0, eht1 eth2
but the porpuse of this
project is using vlan and a bridge so this:
Bridge Orense
eth0.10, eth0.20, eth1.10, eth2.20
It doesn´t work
I don´t know what is wrong here.
Thank´s for your help, I will be checking my
mail to see if anyone has the answer to this.
Bye
___
Yahoo! Sorteos - http://loteria.yahoo.es
Juega a la Lotería Primitiva sin salir de casa
---
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
___
leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
