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