ipcop-devel Mailing List for IPCop Firewall

Ivan Kabaivanov wrote:

> This is how the new boot floppies work:  ipcop-VERSION-boot.img contains the 
> kernel and a tiny initramfs whose only purpose is to try to find an ATAPI 
> CDROM and bootstrap the installer. 

For reason not known yet this fails for me. Looks like "exec run-init 
initramfs /init" fails because of missing /dev/console

Will need to spend more time on this.

Olaf

-- 

A weizen a day helps keep the doctor away.

David W Studeman wrote:

> BTW, not sure if it's too soon to 
> tell but the Option driver binds to my XU870 and in theory it should bring 
> about the same results as setting maxSize at 4096 with the patched usbserial 
> driver in the 1.4 branch but I set one of my browsers to proxy to my 1.9svn 
> box and did a speedtest, it is down quite a bit from what it will do in the 
> 1.4.18 with the usbserial parameters set but I don't trust that the driver is 
> why. 

It is still early days, but since your input has proven invaluable for 
1.4.18, I am hoping that you find time and interest some day to try.


Olaf

-- 

A weizen a day helps keep the doctor away.

David W Studeman schrieb:
> On Saturday 29 December 2007 06:52:07 am Stephan Seitz wrote:
>> hi,
>>
>> maybe it's a dumb question for ipcop developers, but I'm not really
>> familiar with the build procedure of IPCop.
>>
>> My goal is to get an IPCop Image intended to run as paravirtualised domU
>> under Xen. I found some posts in this forum that Xen Support is not a prio
>> / not wanted by the developers, so I'm going to do it at my own.

> 
> Why would you want to do this from the 1.9svn branch? The 1.4 branch is the 
> current stable production branch. 1.9svn is a very volatile place to mess 
> around right now and changes daily, you'll know it's closer to production 
> down the road when it become 2.0a1 or something. Are you trying to run a 
> firewall in a xen environment rather than to be an appliance as it should be? 
> Whatever you do, do NOT run 1.9svn if you even can, between you and the 
> internet!

David, thanks for your reply,

I do know that 1.9 is currently under developing and not ready for production
use. But as Michael already mentioned, I cant rely on 2.4 kernel.

I'll try to explain:

We're migrating whole datacenters into PV and HVM domUs. It affords lots of
possibilities.
- Reduce power cosumption (this is recently a big point)
- Better scalability of single hosts and/or whole appliancies
- Backup/Restore/Setup made easy
and, Yes indeed
- better performance (this is complex, i'll explain this on request)
- lesser total cost of ownership

I see no point, not to have the capabilities to do the very same with the
endless cascades of (mostly older) servers at small and mid-range companies.

To my experience a typical machine park mostly consists of a W2k3 domaincontroller,
one ore two Exchange Servers, a Linux SAMBA Fileserver or a NAS - maybe a second one
as Backupserver, a firewall appliance, often an additional Database Server and
practically always one or two Office PC's running a Desktop Windows with some
fragile 'business solution server'.

Taking this scenario as example, one can have all of this stuff running on one
single mid-range server (maybe 1-2 quad xeons, 16-32G Ram, a good raidcontroller e.g.
areca arc-1220, 8 hdd's in raid-6, 3-5 NICs = about 2500,- to 3500,- EUR) consuming
350 to 750 Watts.

To argue that one will create a single point of failure disregards that formerly
- in most cases - a failure of one machine logically stopped the whole park. Regardless
of the other machines are up and running as they nearly always need all counterparts.

This is why I'm currently spending my spare time with building and testing pre-installed
virtual hosts (aka images). I'm not going to build an off-the-shelf image with IPCop 1.9,
but I primarily like this distro (ahh : thank you! ;) ) and I want to get in touch with
it's build procedure to be prepared when 2.x gets ready.

I'm going to try this as paravirtualized domU, because I want to connect at least the
"red" NIC directly to the virtual host, no bridging or routing, just a PCI-redirect to
have this NIC "physically" available. Theroetically this could be done with fully virtualized
(HVM) virtual hosts (no need to touch the guest OS) also, but this is at least under XEN
a real pain and lacks stability.

Sorry for this lenghy post, but this is my intention... could now someone PLEASE give me
an answer to my primary question?

Thanks in advance!

Regards,

Stephan



-- 
Stephan Seitz
Senior System Administrator

*netz-haut* e.K.
multimediale kommunikation

zweierweg 22
97074 würzburg

fon: +49 931 2876247
fax: +49 931 2876248

web: www.netz-haut.de <http://www.netz-haut.de/>

registriergericht: amtsgericht würzburg, hra 5054

On Sunday 30 December 2007 01:54:20 am Olaf Westrik wrote:
> David W Studeman wrote:
> > So far though, I only used it to try connecting through a 3G
> > cellular card since my cellular data isp nats me anyway. I had to add the
> > ppp device node manually though.
>
> currently I would not even bet on iptables running properly...
>
>
> Olaf

I actually had to manually add dns servers as they would not do so dynamically 
and it wouldn't go out. Just the fact that it even installs and can run doing 
SOMETHING made me pretty happy to see it. BTW, not sure if it's too soon to 
tell but the Option driver binds to my XU870 and in theory it should bring 
about the same results as setting maxSize at 4096 with the patched usbserial 
driver in the 1.4 branch but I set one of my browsers to proxy to my 1.9svn 
box and did a speedtest, it is down quite a bit from what it will do in the 
1.4.18 with the usbserial parameters set but I don't trust that the driver is 
why. It took coaxing just to get it to go to the internet once it got 
connected. I have a Seamonkey installation mapped to that proxy since I don't 
have a good use for Seamonkey anymore with all the other gecko browsers.


Dave

On Sunday 30 December 2007 01:46:48 am Olaf Westrik wrote:
> I'm impressed.
>
> David W Studeman wrote:
> > I would suggest a cobalt branch for 2.0 but it is still a variant of x86.
>
> Not fully sure, might be easier to try and incorporate into 'normal'
> installation. Will need to read again (;-)) and see what's necessary.
>
>
> cheers Olaf

Thanks! A lot of these are coming off of lease now and Brian tells me that a 
lot of people have downloaded our vmware images so far. The devices need the 
latest rom flashed into it but we want to make that part of the network 
install CD. I removed the beep stuff from rc.sysinit and I remapped the 
setting up console fonts to ttyS0 but that gets ignored as it is the wrong 
way to do it. I would like to remove that entry altogether for just the 
headless devices such as this. Before, I would get errors that it couldn't 
find any of the tty's it was looking for and it wouldn't since those tty's 
don't exist on this type of device.

Dave


 

David W Studeman wrote:

> So far though, I only used it to try connecting through a 3G 
> cellular card since my cellular data isp nats me anyway. I had to add the ppp 
> device node manually though.

currently I would not even bet on iptables running properly...


Olaf

-- 

A weizen a day helps keep the doctor away.

I'm impressed.


David W Studeman wrote:
> I would suggest a cobalt branch for 2.0 but it is still a variant of x86. 

Not fully sure, might be easier to try and incorporate into 'normal' 
installation. Will need to read again (;-)) and see what's necessary.


cheers Olaf

-- 

A weizen a day helps keep the doctor away.

Hello folks! I wanted to make mention of a very humble and new project that we 
started last October to make sure we don't step on any toes here. In a 
nutshell, we just take IPCop and make it usable on Gen III Raq hardware and 
make no attempts to act like we did anything other than make IPCop run on 
this hardware and do not take nor deserve any credit for IPCop itself. The 
web address is below: 
 
http://raqcop.com 

Last June I wanted to make IPCop run on a Raq4i that I got for cheap. The 3i 
and 4i come with two 82559er nics and a pci slot and they draw about 40 
watts, aren't usually too noisy and only about a foot deep so they can be 
racked with ears or put on a desktop easily. I wound up adapting a 2.4 Cobalt 
kernel patch to the later ipcop kernel for starters as raqs have no bios and 
use a flashrom that looks for a gzipped or bzipped kernel image in /dev/hda1 
and the root partition which can be specified with the newer rom image that 
is also needed for ext3 support so it gets pointed to hda4 no problem. The 
Cobalt drivers have to be embedded in the zipped kernel image or it won't 
run. Conversely, a cobalt-ized kernel will not boot on a regular x86 system. 
I also wound up patching the e100 driver to ignore the hardware checksum as 
this seems far too common  a mismatch on many implementations of the Intel 
nics. I also had to modify /etc/inittab as the only terminal is now ttyS0 and 
add ttyS0 to securetty. I also added the export argument to /etc/profile to 
set the term type to VT100 so through Minicom, you now can do anything at 
115k that you could do as if there was a keyboard and monitor hooked to any 
regular pc with ipcop on it. What I wound up doing was ONLY modify the 
standard non smp kernel for Cobalt, the installer kernel is normal since I 
use VMWare to make my image and use winimage to expand it to a 20GB cobalt 
drive via a usb to ide adapter. We'll eventually create a cobalt style 
network install that would basically format the drive per normal IPCop 
specifications and unzip the Cobalt-ized build version of the ipcop install 
tarball. During the build process, I have it untar the lcd binaries and 
scripts and also added a section at the bottom of the 386 rootfiles for just 
the LCD stuff. Sun released all this via GPL years back and now members of 
the Linux community are maintaining all this. I have built the LCD scripts 
for Alpine against the devel version of IPCop with no trouble so I have good 
working elf binaries that are in /sbin. All the scripts themselves are perl 
and need to be cleaned up for IPCop specifically. As of now, the easiest 
method for anyone to download and use it is to download the vmware image 
which is only a 107MB image and use winimage and a usb or firewire slaved 
20GB cobalt drive to write back to it. One can also make their own as I 
supply a cdrom image that can be used in a donor machine or vmware as I do. 
The installer kernel is normal with no cobalt drivers so it will let you 
install on anything, just don't try to reboot on VMWare as vmlinuz-2.4.34 is 
NOT present in boot, just vmlinux.bz  and the smp kernel vmlinuz. My VMWare 
image has default passwords and an ip addy. One CAN install with the cd via 
VMWare to a physical drive slaved in via usb or firewire but VMWare sees them 
as scsi so you would then need to mount the drive in Linux with ext3 support, 
go to /dev and change the links from sda > harddisk to hda, 1, 2 etc and 
don't forget to remap.

Now for the SVN version. It appears that it uses only ONE kernel so I may have 
to make a second lfs script specifically for the cobalt kernel but not hard 
to do and just add that to the make.sh. It also appears that the lcd related 
stuff can have it's own rootfiles in this version as of yet. I would 
eventually just want the lcd related stuff to be built via a lfs script which 
is the right way to do it. Jeff Walters 2.6 kernel patch for the latest 2.6 
kernel also works and it already has the patch for the e100 checksum cobalt 
ignore. I would suggest a cobalt branch for 2.0 but it is still a variant of 
x86. 

How did this wind up as a project with it's own site? Well, in ipcops.com my 
signature gives me away as running IPCop on a cobalt so Brian Ridgeway gave 
me a private message not only wanting to know how I did it but also wanted to 
start up a website so in October he did just that and I started uploading my 
work to it. 

My opinion of gen III raq hardware is that it is silly to run a web server on 
such modest hardware that will only work with two drives max and no larger 
than 137GB, the 3i and 4i have two nics and a pci slot. The Symantec 
Velociraptors 500 through at least 1100 are the same platform sans usb and a 
scsi port. The usb could be added with soldering skill and the usb DOES work 
with a usb floppy for backup, then you use that same floppy when making the 
vmware install. I have modified my raptors and 4i's to use the lower voltage 
1.8v core of some k6-III 256k cache 500mhz laptop processors I got from 
someone in Australia. The maximum multiplier is 5.5 although some processors 
will use a 6.0 multiplier with a board multiplier of 2.0. These are solder 
jumpers which consist as 0 ohm surface resistors. By lowering the core to 1.8 
from 2.0 and changing the multiplier to 5.5 and adding this particular 
processor, it runs faster and as cool and power friendly toward the very 
modest built in power supply. I was also successful in clocking two 
Velociraptor 500's from 300mhz and a 2V core to the low voltage 500 clocked 
at 550. 

Dave

This is pasted from my minicom terminal:

root@ipcop:~ # cat /proc/cobalt/sensors/thermal
0 [CPU]: 34.50
root@ipcop:~ # 

root@ipcop:~ # cat /proc/cpuinfo               
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 5
model           : 13
model name      : AMD-K6(tm)-III Processor
stepping        : 0
cpu MHz         : 547.814
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr mce cx8 pge mmx syscall 3dnowext 
3dnow k6_mtrr
bogomips        : 1094.45

On Saturday 29 December 2007 06:34:23 pm David Taylor wrote:
> > Sadly, a lot of things are leaving the ole 2.4 kernel behind in the
> > dust.
> >
> > Dave
>
> Happily, the developers are doing excellent work on the new IPCop and
> things are moving forward.

Yes, I have done a recent build and put it on an old Dell GX100 SFF and it 
runs. I had to use a 32 bit version of openSuSE to make the toolchain as 
Gilles suggested I would and he was right as usual. I did it in VMWare which 
was slow but I have a toolchain now! Now I can build in my 64 bit system no 
problem! So far though, I only used it to try connecting through a 3G 
cellular card since my cellular data isp nats me anyway. I had to add the ppp 
device node manually though.

Dave

> 
> Sadly, a lot of things are leaving the ole 2.4 kernel behind in the
> dust. 
> 
> Dave

Happily, the developers are doing excellent work on the new IPCop and things
are moving forward.

-- 
Dave Taylor

On Saturday 29 December 2007 02:32:59 pm Michael Rasmussen wrote:
> On Sat, 29 Dec 2007 14:19:49 -0800
>
> David W Studeman <avi...@ai...> wrote:
> > Why would you want to do this from the 1.9svn branch? The 1.4 branch
> > is the current stable production branch. 1.9svn is a very volatile
> > place to mess around right now and changes daily, you'll know it's
> > closer to production down the road when it become 2.0a1 or something.
> > Are you trying to run a firewall in a xen environment rather than to
> > be an appliance as it should be? Whatever you do, do NOT run 1.9svn
> > if you even can, between you and the internet!
>
> XEN on 2.4 kernels is no longer under active development, so IPCop 1.4
> and XEN is a no-go.

Sadly, a lot of things are leaving the ole 2.4 kernel behind in the dust. 

Dave

LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMQ0KDQpPbiBTYXQs
IDI5IERlYyAyMDA3IDE0OjE5OjQ5IC0wODAwDQpEYXZpZCBXIFN0dWRlbWFuIDxhdmlvbmljc2R2
QGFpbS5jb20+IHdyb3RlOg0KDQo+IFdoeSB3b3VsZCB5b3Ugd2FudCB0byBkbyB0aGlzIGZyb20g
dGhlIDEuOXN2biBicmFuY2g/IFRoZSAxLjQgYnJhbmNoDQo+IGlzIHRoZSBjdXJyZW50IHN0YWJs
ZSBwcm9kdWN0aW9uIGJyYW5jaC4gMS45c3ZuIGlzIGEgdmVyeSB2b2xhdGlsZQ0KPiBwbGFjZSB0
byBtZXNzIGFyb3VuZCByaWdodCBub3cgYW5kIGNoYW5nZXMgZGFpbHksIHlvdSdsbCBrbm93IGl0
J3MNCj4gY2xvc2VyIHRvIHByb2R1Y3Rpb24gZG93biB0aGUgcm9hZCB3aGVuIGl0IGJlY29tZSAy
LjBhMSBvciBzb21ldGhpbmcuDQo+IEFyZSB5b3UgdHJ5aW5nIHRvIHJ1biBhIGZpcmV3YWxsIGlu
IGEgeGVuIGVudmlyb25tZW50IHJhdGhlciB0aGFuIHRvDQo+IGJlIGFuIGFwcGxpYW5jZSBhcyBp
dCBzaG91bGQgYmU/IFdoYXRldmVyIHlvdSBkbywgZG8gTk9UIHJ1biAxLjlzdm4NCj4gaWYgeW91
IGV2ZW4gY2FuLCBiZXR3ZWVuIHlvdSBhbmQgdGhlIGludGVybmV0IQ0KPiANClhFTiBvbiAyLjQg
a2VybmVscyBpcyBubyBsb25nZXIgdW5kZXIgYWN0aXZlIGRldmVsb3BtZW50LCBzbyBJUENvcCAx
LjQNCmFuZCBYRU4gaXMgYSBuby1nby4NCg0KLSAtLSANCkhpbHNlbi9SZWdhcmRzDQpNaWNoYWVs
IFJhc211c3Nlbg0KDQpHZXQgbXkgcHVibGljIEdudVBHIGtleXM6DQptaWNoYWVsIDxhdD4gcmFz
bXVzc2VuIDxkb3Q+IGNjDQpodHRwOi8va2V5c2VydmVyLnZlcmlkaXMuY29tOjExMzcxL3Brcy9s
b29rdXA/b3A9Z2V0JnNlYXJjaD0weEQzQzlBMDBFDQptaXIgPGF0PiBkYXRhbm9tIDxkb3Q+IG5l
dA0KaHR0cDovL2tleXNlcnZlci52ZXJpZGlzLmNvbToxMTM3MS9wa3MvbG9va3VwP29wPWdldCZz
ZWFyY2g9MHhFNTAxRjUxQw0KbWlyIDxhdD4gbWlyYXMgPGRvdD4gb3JnDQpodHRwOi8va2V5c2Vy
dmVyLnZlcmlkaXMuY29tOjExMzcxL3Brcy9sb29rdXA/b3A9Z2V0JnNlYXJjaD0weEUzRTgwOTE3
DQotIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tDQpJZiB0aGUgcG9saWNlIGFycmVzdCBhIG1pbWUsIGRvIHRoZXkgdGVsbCBoaW0g
aGUgaGFzIHRoZSByaWdodCB0bw0KcmVtYWluIHNpbGVudD8NCi0tLS0tQkVHSU4gUEdQIFNJR05B
VFVSRS0tLS0tDQpWZXJzaW9uOiBHbnVQRyB2MS40LjYgKEdOVS9MaW51eCkNCg0KaUQ4REJRRkhk
c3NiVkVyWVZlUG9DUmNSQXBsNUFKOXY1Qkd4SUQ0c291WFpMNE9TZk9hcVBkNzZLZ0NncEhnUQ0K
aFNWUmZmMW52ZTZheVN2RFIzY2pUOVU9DQo9Sm1CTA0KLS0tLS1FTkQgUEdQIFNJR05BVFVSRS0t
LS0tDQo=

On Saturday 29 December 2007 06:52:07 am Stephan Seitz wrote:
> hi,
>
> maybe it's a dumb question for ipcop developers, but I'm not really
> familiar with the build procedure of IPCop.
>
> My goal is to get an IPCop Image intended to run as paravirtualised domU
> under Xen. I found some posts in this forum that Xen Support is not a prio
> / not wanted by the developers, so I'm going to do it at my own.
>
> What I've done so long:
>
> - get latest changeset from SVN
> - ./make.sh prefetch
> - ./make.sh build
> - copied over Xen kernel patches for 2.6.22 (extracted from Ubuntu Gutsy
> SRC .deb) - ./make.sh shell , following inside chroot:
> - cp -dpar /usr/src/linux-2.6.22 /usr/src/linux-2.6.22-xen
> - patched the linux-2.6.22-xen
> - modified kernel .config (slightly, changed arch from PC/486 to
> Xen/x86-PAE, buildin blkfront, netfront - no further changes) - this kernel
> should also boot bare-matel.
> - make && make modules_install && make install && depmod -aq 2.6.22-xen
> - cleaned up /boot
>
>
> But, what to do next to get this installed in the "IPCop"-way?
>
> I've got a nice installation tree, but a quick peek showed me only a very
> basic system. Maybe I missed something, but I don't know how to get e.g.
> httpd / apache installed "the right way" or the SVN trunk/html copied
> inside.
>
> Could someone tell me how to get a running IPCop out of this build stage?
>
> Thanks in advance!
>
> Stephan

Why would you want to do this from the 1.9svn branch? The 1.4 branch is the 
current stable production branch. 1.9svn is a very volatile place to mess 
around right now and changes daily, you'll know it's closer to production 
down the road when it become 2.0a1 or something. Are you trying to run a 
firewall in a xen environment rather than to be an appliance as it should be? 
Whatever you do, do NOT run 1.9svn if you even can, between you and the 
internet!


Dave

On Tue, 25 Dec 2007 ja...@gu... wrote:

>> Hello Yvan,
>> What really make sense here is simply that
>> building an 1.4 on k2.6 give NOTHING
>> for old old machines. The actual 1.4 does
>> the job without any loss of functionality.
>>
>> The ONLY reason given to choose the formula
>> 1.4 on strong k2.6 is 'new hardware'.
>>
>> So, remove obsolete support, like ISA and floppies,
>> and work on actual methods of today that will be
>> obsolete tomorrow....
>> work on today's hardwareSSSSSSSSSSS,
>
> So we are back to tossing hardware, what because it is too hard?
>
> I have Dual PPro machines with ISA slots... so I am to lose hardware
> usability.
>
> So, what now is the hardware target for V2, a 1.5G processor with
> 512M of memory, w/ USB2.0 only support.
>

   FWIW, I am using an old Sony Vio:

   Pentium (original, no fan) 200Mhz
   64MB
   4 GB IDE disk
   sony branded CDROM
   USB, (ancient and mostly non-functional, except for a mouse, so no
   usb sticks).

   Although the machine could boot of off the CDROM, the boot loader
   would choke on some obscure error (sorry, should have written it
   down) and hang.

   Using the install floppy image allowed the ipcop kernel to load, and
   from there it could boot strap off of the CDROM.  So in my case, the
   floppy boot-strap option was the only way to use this hardware at
   all.

   It runs great, and I get an additional 100KB/sec throughput compared
   to the Sonicwall SOHO it replaced :)

   So, please continue supporting 'old' hardware.

> jackb
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> IPCop-devel mailing list
> IPC...@li...
> https://lists.sourceforge.net/lists/listinfo/ipcop-devel
>

-- 
Happy cheese in fear                 | Jon Trulson
against oppressor, rebel!            | mailto:jo...@ra...
Brocolli, hostage.       -Unknown    | #include <std/disclaimer.h>

hi,

maybe it's a dumb question for ipcop developers, but I'm not really familiar with the build procedure of IPCop.

My goal is to get an IPCop Image intended to run as paravirtualised domU under Xen. I found some posts in this forum
that Xen Support is not a prio / not wanted by the developers, so I'm going to do it at my own.

What I've done so long:

- get latest changeset from SVN
- ./make.sh prefetch
- ./make.sh build
- copied over Xen kernel patches for 2.6.22 (extracted from Ubuntu Gutsy SRC .deb)
- ./make.sh shell , following inside chroot:
- cp -dpar /usr/src/linux-2.6.22 /usr/src/linux-2.6.22-xen
- patched the linux-2.6.22-xen
- modified kernel .config (slightly, changed arch from PC/486 to Xen/x86-PAE, buildin blkfront, netfront - no further
changes) - this kernel should also boot bare-matel.
- make && make modules_install && make install && depmod -aq 2.6.22-xen
- cleaned up /boot


But, what to do next to get this installed in the "IPCop"-way?

I've got a nice installation tree, but a quick peek showed me only a very basic system. Maybe I missed something, but I
don't know how to get e.g. httpd / apache installed "the right way" or the SVN trunk/html copied inside.

Could someone tell me how to get a running IPCop out of this build stage?

Thanks in advance!

Stephan




-- 
Stephan Seitz
Senior System Administrator

*netz-haut* e.K.
multimediale kommunikation

zweierweg 22
97074 würzburg

fon: +49 931 2876247
fax: +49 931 2876248

web: www.netz-haut.de <http://www.netz-haut.de/>

registriergericht: amtsgericht würzburg, hra 5054

Robert Kerr wrote:

> If you see any more just throw the logs my way and I'll see about
> further Makefile patches.

here's one for slang, most of the time it builds, every so often it breaks.
AMD X2 with parallelism 3


Olaf


Dec 28 18:18:49: Building slang
slang-2.0.7.tar.bz2 checksum OK
+ cd /usr/src/lfs
+ make -f slang LFS_BASEDIR=/usr/src install
====================================== Installing slang-2.0.7 ...
Install started; saving file list to /usr/src/lsalr ...
cd /usr/src/slang-2.0.7 && CFLAGS="-Os -fomit-frame-pointer -Wall 
-fPIC" ./configure	--prefix=/usr \
											--disable-pcre \
											--disable-png \
											--disable-readline
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking for egrep... grep -E
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking how to run the C preprocessor... gcc -E
checking whether gcc needs -traditional... no
checking for library containing strerror... none required
checking for AIX... no
checking C compiler that understands ANSI prototypes... gcc looks ok.  Good.
checking whether make sets $(MAKE)... yes
checking for ranlib... ranlib
checking for a BSD-compatible install... /usr/bin/install -c
checking for X... no
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for stdlib.h... (cached) yes
checking for unistd.h... (cached) yes
checking for memory.h... (cached) yes
checking termios.h usability... yes
checking termios.h presence... yes
checking for termios.h... yes
checking malloc.h usability... yes
checking malloc.h presence... yes
checking for malloc.h... yes
checking locale.h usability... yes
checking locale.h presence... yes
checking for locale.h... yes
checking langinfo.h usability... yes
checking langinfo.h presence... yes
checking for langinfo.h... yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking sys/fcntl.h usability... yes
checking sys/fcntl.h presence... yes
checking for sys/fcntl.h... yes
checking for sys/types.h... (cached) yes
checking sys/wait.h usability... yes
checking sys/wait.h presence... yes
checking for sys/wait.h... yes
checking sys/utsname.h usability... yes
checking sys/utsname.h presence... yes
checking for sys/utsname.h... yes
checking sys/times.h usability... yes
checking sys/times.h presence... yes
checking for sys/times.h... yes
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking floatingpoint.h usability... no
checking floatingpoint.h presence... no
checking for floatingpoint.h... no
checking ieeefp.h usability... no
checking ieeefp.h presence... no
checking for ieeefp.h... no
checking nan.h usability... no
checking nan.h presence... no
checking for nan.h... no
checking fenv.h usability... yes
checking fenv.h presence... yes
checking for fenv.h... yes
checking sys/mman.h usability... yes
checking sys/mman.h presence... yes
checking for sys/mman.h... yes
checking sys/socket.h usability... yes
checking sys/socket.h presence... yes
checking for sys/socket.h... yes
checking for sys/socket.h... (cached) yes
checking netinet/in.h usability... yes
checking netinet/in.h presence... yes
checking for netinet/in.h... yes
checking arpa/inet.h usability... yes
checking arpa/inet.h presence... yes
checking for arpa/inet.h... yes
checking sys/un.h usability... yes
checking sys/un.h presence... yes
checking for sys/un.h... yes
checking for mode_t... yes
checking for pid_t... yes
checking for uid_t in sys/types.h... yes
checking for size_t... yes
checking for socklen_t... yes
checking for dirent.h that defines DIR... yes
checking for library containing opendir... none required
checking for memset... yes
checking for memcpy... yes
checking for putenv... yes
checking for getcwd... yes
checking for setlocale... yes
checking for tcgetattr... yes
checking for tcsetattr... yes
checking for cfgetospeed... yes
checking for sigaction... yes
checking for sigemptyset... yes
checking for sigprocmask... yes
checking for sigaddset... yes
checking for alarm... yes
checking for pause... yes
checking for vfscanf... yes
checking for lstat... yes
checking for readlink... yes
checking for symlink... yes
checking for link... yes
checking for kill... yes
checking for snprintf... yes
checking for vsnprintf... yes
checking for getppid... yes
checking for getegid... yes
checking for geteuid... yes
checking for getuid... yes
checking for getgid... yes
checking for setgid... yes
checking for setpgid... yes
checking for setuid... yes
checking for mmap... yes
checking for chown... yes
checking for popen... yes
checking for mkfifo... yes
checking for atexit... yes
checking for on_exit... yes
checking for umask... yes
checking for uname... yes
checking for times... yes
checking for gmtime... yes
checking for mktime... yes
checking for gettimeofday... yes
checking for strtod... yes
checking for atoll... yes
checking for strtoll... yes
checking for issetugid... no
checking for isnan... yes
checking for finite... yes
checking for isinf... yes
checking for round... no
checking for siglongjmp... yes
checking for nl_langinfo and CODESET... yes
checking for acosh in -lm... yes
checking for asinh in -lm... yes
checking for atanh in -lm... yes
checking for hypot in -lm... yes
checking for atan2 in -lm... yes
checking for feclearexcept in -lm... yes
checking for fpsetsticky in -lm... no
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking for dlopen in -ldl... yes
checking for short... yes
checking size of short... 2
checking for int... yes
checking size of int... 4
checking for long... yes
checking size of long... 4
checking for float... yes
checking size of float... 4
checking for double... yes
checking size of double... 8
checking for long long... yes
checking for long long... (cached) yes
checking size of long long... 8
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... 64
checking for _LARGE_FILES value needed for large files... no
checking for _LARGEFILE_SOURCE value needed for large files... no
checking for fseeko... yes
checking for off_t... yes
checking for off_t... (cached) yes
checking size of off_t... 8
checking for Terminfo... yes
checking for the pcre library and header files ... yes: /usr/lib and 
/usr/include
checking for the png library and header files ... yes: /usr/lib and 
/usr/include
checking type of readline support for slsh... slang
checking SLANG_VERSION... 2.0.7
configure: creating ./config.status
config.status: creating Makefile
config.status: creating src/Makefile
config.status: creating slsh/Makefile
config.status: creating modules/Makefile
config.status: creating demo/Makefile
config.status: creating src/sysconf.h

Configuration complete.  You may need to edit src/Makefile.
You are compiling SLANG with the following compiler configuration:
        CC = gcc
    CFLAGS = -Os -fomit-frame-pointer -Wall -fPIC
   LDFLAGS =  -Wl,-export-dynamic

    ELF_CC = $(CC)
  ELF_LINK = $(CC) $(LDFLAGS) -shared -Wl,-O1 
-Wl,--version-script,$(VERSION_SCRIPT) -Wl,-soname,$(ELFLIB_MAJOR)
ELF_CFLAGS= $(CFLAGS) -fPIC

                   prefix: /usr
              exec_prefix: ${prefix}
     Installation Lib Dir: ${exec_prefix}/lib
Installation Include Dir: ${prefix}/include

See also src/sl-feat.h for various features.
Type 'make' to build normal library.
On ELF systems, type 'make elf' to create ELF shared library.
cd /usr/src/slang-2.0.7 && sed -i 's/^#define 
SLANG_OPTIMIZE_FOR_SPEED.*$/#define SLANG_OPTIMIZE_FOR_SPEED 0/' \
											src/sl-feat.h
cd /usr/src/slang-2.0.7 && sed -i 's/^#define 
SLANG_HAS_DEBUGGER_SUPPORT.*$/#define SLANG_HAS_DEBUGGER_SUPPORT 0/' \
											src/sl-feat.h
cd /usr/src/slang-2.0.7 && CFLAGS="-Os -fomit-frame-pointer -Wall -fPIC" 
make -j 3
make[1]: Entering directory `/usr/src/slang-2.0.7'
cd src; make all
make[2]: Entering directory `/usr/src/slang-2.0.7/src'
mkdir /usr/src/slang-2.0.7/src/objs
cp sysconf.h config.h
cd /usr/src/slang-2.0.7/src/objs; gcc -c -Os -fomit-frame-pointer -Wall 
-fPIC  -Dunix -DSLANG -DMISC_TERMINFO_DIRS='""' 
/usr/src/slang-2.0.7/src/sltermin.c
cd /usr/src/slang-2.0.7/src/objs; gcc -c -Os -fomit-frame-pointer -Wall 
-fPIC  -Dunix -DSLANG  /usr/src/slang-2.0.7/src/sldisply.c
/bin/sh: line 0: cd: /usr/src/slang-2.0.7/src/objs: No such file or 
directory
cd /usr/src/slang-2.0.7/src/objs; gcc -c -Os -fomit-frame-pointer -Wall 
-fPIC  -Dunix -DSLANG  /usr/src/slang-2.0.7/src/slutty.c

.....

cd /usr/src/slang-2.0.7/src/objs; gcc -c -Os -fomit-frame-pointer -Wall 
-fPIC  -Dunix -DSLANG  /usr/src/slang-2.0.7/src/slboseos.c
rm -f /usr/src/slang-2.0.7/src/objs/libslang.a
cd /usr/src/slang-2.0.7/src/objs; ar cr libslang.a sltermin.o sldisply.o 
slutty.o slang.o slarray.o slclass.o slcmd.o slerr.o slgetkey.o 
slkeymap.o slmalloc.o slmath.o slmemchr.o slmemcmp.o slmemcpy.o 
slmemset.o slmisc.o slparse.o slprepr.o slregexp.o slrline.o slsearch.o 
slsmg.o slstd.o sltoken.o sltypes.o slxstrng.o slcurses.o slscroll.o 
slsignal.o slkeypad.o slerrno.o slstring.o slstruct.o slcmplex.o 
slarrfun.o slimport.o slpath.o slarith.o slassoc.o slcompat.o slposdir.o 
slstdio.o slproc.o sltime.o slstrops.o slbstr.o slpack.o slintall.o 
slistruc.o slposio.o slnspace.o slarrmis.o slospath.o slscanf.o 
sllower.o slupper.o slischar.o slutf8.o slwcwidth.o slwclut.o slcommon.o 
sllist.o slexcept.o slfpu.o slsig.o slboseos.o
ar: sltermin.o: No such file or directory
make[2]: *** [/usr/src/slang-2.0.7/src/objs/libslang.a] Error 1
make[2]: Leaving directory `/usr/src/slang-2.0.7/src'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/usr/src/slang-2.0.7'
make: *** [/usr/src/log_i486/04_misc/slang-2.0.7] Error 2


-- 

A weizen a day helps keep the doctor away.

Ivan Kabaivanov wrote:

> Also can you look into the locale archive and only include the english text on 
> ipcop-VERSION-root.img?

The way I see it we'll need the locale-archive only to be able to 
display those funny characters used in non-English languages.

As it is now it must also be in /usr/lib/locale and not in /lib/locale 
otherwise the characters don't work.
I can try to find where the location of locale-archive is set, or we 
re-include /usr/lib/locale. Opinions ?


Should we decide to drop languages for the 'floppy installer' altogether 
or at least the first few questions about drivers and additional disks 
we don't need locale-archive. That would save close to 300 KB in the 
root image.


cheers Olaf

-- 

A weizen a day helps keep the doctor away.

LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMQ0KDQpPbiBUaHUs
IDI3IERlYyAyMDA3IDA0OjE3OjQ5IC0wNTAwDQpJdmFuIEthYmFpdmFub3YgPGNoZXBhdGlAeWFo
b28uY29tPiB3cm90ZToNCg0KPiANCj4gSSB3YW50IHRvIGZpeCBhIHNtYWxsIHByb2JsZW0gd2l0
aCB0aGUgcG93ZXJwYyBpbnN0YWxsIGZsb3BwaWVzIGFuZA0KPiB0aGVuIEknbGwgaGF2ZSB0aW1l
IHRvIHdvcmsgb24geDg2XzY0IGhvc3QgYnVpbGRpbmcuICBJIHdpbGwgdHJ5IHRvDQo+IGRvIHRo
aXMgYmVmb3JlIHRoZSBlbmQgb2YgdGhlIHllYXIsIGJ1dCB0aGVzZSBkYXlzIEknbSBhIGxpdHRs
ZQ0KPiBsYXp5IDotKQ0KPiANClJlbWVtYmVyLCBsYXppbmVzcyBpcyB0aGUgcm9vdCBmb3IgYWxs
IGV2aWw6LSkNCg0KPiBGaXhpbmcgdGhlIGJ1aWxkIHNjcmlwdCBpcyBteSBwcmVmZXJyZWQgYXBw
cm9hY2ggc28gdGhhdCdzIHdoeSBJDQo+IGhhdmVuJ3QgYXBwbGllZCB5b3VyIHBhdGNoLg0KPiAN
CkZhaXIgZW5vdWdoLg0KDQotIC0tIA0KSGlsc2VuL1JlZ2FyZHMNCk1pY2hhZWwgUmFzbXVzc2Vu
DQoNCkdldCBteSBwdWJsaWMgR251UEcga2V5czoNCm1pY2hhZWwgPGF0PiByYXNtdXNzZW4gPGRv
dD4gY2MNCmh0dHA6Ly9rZXlzZXJ2ZXIudmVyaWRpcy5jb206MTEzNzEvcGtzL2xvb2t1cD9vcD1n
ZXQmc2VhcmNoPTB4RDNDOUEwMEUNCm1pciA8YXQ+IGRhdGFub20gPGRvdD4gbmV0DQpodHRwOi8v
a2V5c2VydmVyLnZlcmlkaXMuY29tOjExMzcxL3Brcy9sb29rdXA/b3A9Z2V0JnNlYXJjaD0weEU1
MDFGNTFDDQptaXIgPGF0PiBtaXJhcyA8ZG90PiBvcmcNCmh0dHA6Ly9rZXlzZXJ2ZXIudmVyaWRp
cy5jb206MTEzNzEvcGtzL2xvb2t1cD9vcD1nZXQmc2VhcmNoPTB4RTNFODA5MTcNCi0gLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N
CkJPRkggZXhjdXNlICM0MjI6DQoNClNvbWVvbmUgZWxzZSBzdG9sZSB5b3VyIElQIGFkZHJlc3Ms
IGNhbGwgdGhlIEludGVybmV0IGRldGVjdGl2ZXMhDQotLS0tLUJFR0lOIFBHUCBTSUdOQVRVUkUt
LS0tLQ0KVmVyc2lvbjogR251UEcgdjEuNC42IChHTlUvTGludXgpDQoNCmlEOERCUUZIZEtSVFZF
cllWZVBvQ1JjUkF2NC9BSjlUZkpCL0daYkx0UzNReENZaEh3TTI1ZDM5UFFDZUtUb2sNCm5LK3lv
SnRxKytqTjhlbW1qa2VyS3d3PQ0KPUVTbEUNCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQ0K

Le jeudi 27 décembre 2007 21:10, ta...@co... a écrit :
> I love IPCop and I wouldn't run a network without it.  It does make me a
> little nervous when you guys fight though.  It would be awful if there
> wasn't IPCop.  Thanks to everyone for keeping my computers safe all these
> years. --R
>
>

There are some real challengers around. People alone or
as Smoothwall in the past, releasing/publishing their 
products.

So, asking when IPcop will provide new firewall features* 
is far from innocent.
It seems I'm a little bit hurry on new design and priority is 
given as indicated in the subject ;-)

It's just a question of time because a lot of us develop
its own addon and thus, knows limitations of 1.4 code.

If one day decision is made to step up IPcop, lots
of features will be de facto integrated, lots of addon
will disappear. And it is difficult to admit that two or
three years of line coding are going to trash. Or
loose some kind of recognition, who knows?





Tchuss 

On Thursday 27 December 2007 12:10:42 pm ta...@co... wrote:
> I love IPCop and I wouldn't run a network without it.  It does make me a
> little nervous when you guys fight though.  It would be awful if there
> wasn't IPCop.  Thanks to everyone for keeping my computers safe all these
> years. --R
>
>

Nah, this is nothing to be nervous about and definitely not a fight. Mainly an 
exchange between one person and the rest of them. A lot of those with access 
to make changes have quit the discussion and went back to work by now. No 
worries.


Dave

I love IPCop and I wouldn't run a network without it.  It does make me a
little nervous when you guys fight though.  It would be awful if there
wasn't IPCop.  Thanks to everyone for keeping my computers safe all these
years. --R

Franck Bourdonnec schrieb:
> Le jeudi 27 décembre 2007 15:12, Tom Eichstaedt a écrit :
>> Franck Bourdonnec wrote:
>>> I allways ear "no developpers, no time, no ....."
>>> False: look number of addons available. Behind each addon is
>>> a developper or a team. Waiting to write a part of IPCop.
>> May be you did not recognize that Olaf (and Gilles) are in close contact
>> with many developers of popular and important addons and enhancements.
>>
>> Just to mention some of them:
>>
>> horizont (aka Ufuk):Zerina, OpenVPN
>> dotzball (aka Achim): BlockOutTraffic (BOT), Net-Traffic ...
>> weizen_42 (aka Olaf): Conn Scheduler, CopSpot, Dialin Server, Extra
>> Ifaces, HDDGraph, iptables GUI, mbmongraph, Munin, Wake On LAN, WLAN AP,
>> Dialup Monitor, ...
>> zisoft (aka Mario): modified mkflash (allready part of IPCop v1.4.18)
>> marco.s: Advanced webproxy addon, WPAD, Calamaris,URL filter addon, CRE
>> Classroom Extension, Update Accelerator addon, ...
>> SimondP: RAMCop, AddPartition, GrubGUI, ...
>> sfeddersen: UPS Server, Webalizer, LineTest, Who is online, ...
>>
>> Due to the fact that all of them are members of the german IPCop
>> community and/or allready joined the IPCop team there is a very, very
>> good exchange of information (and code) between Olaf (as v2.0
>> dev.leader/release manager) and the addon developers for IPCop v2.0.
>>
>> Cheers, Tom
>>
> 
> half of thoses are not addons but just some
> currative patches because of the old specs.
> The other half is real new applis that maybe usefull for certain
> circumstancies.
> Support for those addons.? Nothing. Especially from end users's
> point of view. Is something like 'addonmanager' available? no.
> Can interaction exists between addons? no.
> Support for developpers....embryon with language support.
> 
> Resources are just waiting for defining IPCop2.

Obviously you changed the topic because you do not like what I answered.
Nevertheless I'm sure the message has reached you.

Cheers Tom (who stops talking to you now)

Le jeudi 27 décembre 2007 14:20, Gilles Espinasse a écrit :
>
> Please stop posting contradicting yourself.
> You ask a day to rewrite spec from scratch and the day before that
> we should mandatory just make next version strictly a 1.4 with a 2.6
> kernel. We can't simply understand you.
it was the result of discussions 6 months ago.


> You have asked for a manager, but you are impossible to manage.
> I have been forced to remove your write access on CVS when you start again
> doing development on 1.4 instead of working on next version.
What next version?, Yes, the magic person able to say "OK we remove this 
limitation, the consequence is....big" is absent.
And sorry if compiling linux kernel with glibc version X instead of klibZ is
not really interesting me.

> We have the freedom to select our evolution path and if it does not match
> the way you want, you are free to go somewhere else.
and i have freedom to tell why I think it maybe wrong.

Just look at the Roadmap.
-from users viewpoint, who is looking for a firewall.
--new interface. so what? is the interface protecting my net? no
--openvpn. I have it today with addon. What more is provided?
--and don't forget abality to control output trafic, already known as 
BOTaddon.
nothing new for security aspect. Who will try that?

now from developpers:
the first mid long term goal is  "Support multiples interfaces".
This one just implies rethinking 2/3 or IPCop.

There is no reason to delay it again. It is a blocking point
since 1.1 specs. 7 years.

> You have been a great help for me and IPCop. That's no more the case since
> to much time.

until accepting this step, developping on the IPCop code is wasting time 
because when that fact will be accepted, a lot of code will be discarded.
Simply because the base IPcop will provide differrent rules of interacting
between identified parts (GUI, CONFIG-BACKUP, FIREWALL, APPS-ADDON,...).

The big problem is not writting all at a time but designing the system to
be extensible.

Just an example:
Stating that one day all the configuration system will run outside of the fw*
implies some design rules. No more. Implementation will follow one
day under VM or other common management interface. But the rules
are known today. 

*wich is obviously a good point for security of the box
>
> Gilles
>
Franck

Le jeudi 27 décembre 2007 15:12, Tom Eichstaedt a écrit :
> Franck Bourdonnec wrote:
> > I allways ear "no developpers, no time, no ....."
> > False: look number of addons available. Behind each addon is
> > a developper or a team. Waiting to write a part of IPCop.
>
> May be you did not recognize that Olaf (and Gilles) are in close contact
> with many developers of popular and important addons and enhancements.
>
> Just to mention some of them:
>
> horizont (aka Ufuk):Zerina, OpenVPN
> dotzball (aka Achim): BlockOutTraffic (BOT), Net-Traffic ...
> weizen_42 (aka Olaf): Conn Scheduler, CopSpot, Dialin Server, Extra
> Ifaces, HDDGraph, iptables GUI, mbmongraph, Munin, Wake On LAN, WLAN AP,
> Dialup Monitor, ...
> zisoft (aka Mario): modified mkflash (allready part of IPCop v1.4.18)
> marco.s: Advanced webproxy addon, WPAD, Calamaris,URL filter addon, CRE
> Classroom Extension, Update Accelerator addon, ...
> SimondP: RAMCop, AddPartition, GrubGUI, ...
> sfeddersen: UPS Server, Webalizer, LineTest, Who is online, ...
>
> Due to the fact that all of them are members of the german IPCop
> community and/or allready joined the IPCop team there is a very, very
> good exchange of information (and code) between Olaf (as v2.0
> dev.leader/release manager) and the addon developers for IPCop v2.0.
>
> Cheers, Tom
>

half of thoses are not addons but just some
currative patches because of the old specs.
The other half is real new applis that maybe usefull for certain
circumstancies.
Support for those addons.? Nothing. Especially from end users's
point of view. Is something like 'addonmanager' available? no.
Can interaction exists between addons? no.
Support for developpers....embryon with language support.

Resources are just waiting for defining IPCop2.

Le jeudi 27 décembre 2007 15:23, Michael Rasmussen a écrit :
> On Thu, 27 Dec 2007 09:14:24 -0500
>
> Phil Barnett <ph...@ph...> wrote:
> > You obviously did not know Richard. What you state above was
> > definitely not happening. If it was, there would be no IPCop.
no ,  i don't know him.

>
> He, he, The dear Richard (II)
>
> As I recall it, I joined the translation team back when it was
> smothwall 0.9.8, it was conquer, but no divide. No idea had any change
> of propagating unless the master himself approved and anything he made
> was added without proper discussion among team members, and likely not
> known to others before their work was scrapped.
>
> Not to mention the heated debate about GPL!

for non english readers, what must be understood here?

King Richiard II was deciding himself everything or it is the
exact inverse ?

Franck