What do you want from Pyramid Linux

[JohnC]

I am going to be working on updating Pyramid over time. I am looking
for any input as what you the users would like.

Thanks John

[Alan]

Hi John,

Can you add Named (dns) and Ralink drivers?
Is it passible to keep the DHCP leases list and the RRD graphs after
reboot, and can you add a page withs display the active and history
DHCP leases?.
Can you add local users for the captiveportal so you don't need a
external database?
Can you add a page with firewall roules?

thanks
Regards,

Alan Janssen

[C.J. Adams-Collier]

Hey there John,

I'd like to see the PXE update software become a bit more robust.
Right now, it seems that it's expected for the maintainer to put a PXE
disk in their system and boot it in order to upgrade the firmware. I
think that some modifications to DHCP and DNS servers will greatly
ease the task of the node admin. Fallback to the status quo would
ensure that the current implementation continues to work.

I've also noticed that manual intervention is often required in order
to bring the node back online. Building the watchdog timer into the
kernel (rather than having it loaded by the initrd or the runtime
filesystem) may reduce the chance of the kernel getting into a panic/
hang state which can only be resolved by a power cycle.

I'm happy to contribute patches.

Cheers,

C.J.

[garlicsalt2]

Hello all,

I am running Pyramid Linux on an old Toshiba laptop.
I have an LG PM 225 Cell phone, for Sprint/CDMA, and a Data cable,
from MyBat.
I have loaded the kernel module for it, and it is seen, as /dev/
ttyACM0.
On the Web Config page, does not see a cellular connection. How do I
set this up??
Oh, yeah, the kernel module I use is cdc_acm, if that helps.


I am also using an Atheros 5212 A/B/G PC-MCIA card. (Specifically, a D-
Link AG-660)
MadWiFi seems to run fine, all-in-all, but sometimes the ath0
interface doesn't come up on startup.
I'm pretty good with computers in general, and with Linux, but I don't
know if there is a way to watch for the sudden appearance of wifi0 net
if (such as for insertion fo PC Card after boot), and issue an "ifup
ath0" at such time. Is there a way to hook into hotplug/udev, to
accomplish this?

Lastly, what would I have to do to enable regular console access on my
laptop? Currently, I have a null-modem cable hooked to my Windows PC,
and Putty running over the Serial connection.

Whew! My fingers are tired...

--Aaron

[JohnC]

Aaron,

Did you add the module to /etc/init.d/cellular-modules, also you need
to create or edit a couple files file in /etc/ppp/peers
/etc/ppp/peers/gprs_vodafone

hide-password
noauth
connect "/usr/sbin/chat -v -f /etc/ppp/peers/gprs_vodafone"
debug
-crtscts
/dev/usb/ttyACM0
57600
defaultroute
noipdefault
remotename gprs_vodafone
ipparam gprs_vodafone
usepeerdns
logfile "/var/log/pppd.log"

and
/etc/ppp/peers/gprs_vodafone
ABORT BUSY
ABORT 'NO CARRIER'
ABORT VOICE
ABORT 'NO DIALTONE'
ABORT 'NO DIAL TONE'
ABORT 'NO ANSWER'
ABORT DELAYED
'' ATZ
OK-AT-OK AT+CGDCONT=1,"IP","web.omnitel.it"
OK-AT-OK AT+CGQREQ=1,2,4,3,6,31
OK-AT-OK AT+CGQMIN=1,2,4,3,6,31
OK-AT-OK AT+CGATT=1 OK-AT-OK ATD*99#
CONNECT ''

you will also need to add your dns server to /etc/resolv.conf

as far as the pcmcia card you need to change when pcmcia starts in the
rc2.d and rcS.d to S20pcmcia from what it currently is, what is
happening is that it loads madwifi before the card is loaded.

and..
for you to gain console access on the laptop screen you need to change
the menu in /lib/grub/i386-pc/menu.lst

title Metrix
root (hd0,0)
kernel /boot/vmlinuz root=/dev/hda1 console=ttyS0,19200n8

to

title Metrix
root (hd0,0)
kernel /boot/vmlinuz root=/dev/hda1

feel free to upload your workin ppp config files to here

John

[maroc]

What I would like to see more than anything for Pyramid is a full
featured web config. Wifi Admin does take care of the basics but it
doesn't really offer the features one would expect for a wireless
router. Projects like tomato and m00nwall have incredible web based
configuration systems. Unfortunately, Tomato only works on specific
off the shelf routers and m00nwall runs on freebsd which doesn't have
support for hardware such as 3g modems and many 802.11 cards.

I'm not one to reinvent the wheel so I've started looking at the
sources for the web configs for tomato and m00nwall. It's definitely
possible to modify either of these to work with pyramid's subsystem
but its going to take work. I think tomato is best but the author
requires his permission to use it.

Any interest in getting one of these or another fully featured web
config into pyramid? I'm willing to help out where I can but my time
is limited at the moment. I think having a fully featured web config
would put pyramid over the top compared to most other embedded linux
distros targeted for x86 router boards.

Marshall

[Joseph O'Donnell]

Hello All,
Thanks for the very useful Pyramid Linux project. I haven't worked with
it for a while although probably will again, so some of these features
may already be present:

#1 apt-get

#2 a repository with deb binaries for the popular embedded, micro and
nano boards:
-gnu build chain
-temperature sensor drivers
-lcd drivers
-usb drivers

#3 whatever packages, configurations and documentation are necessary to
allow easy use and full control of the usb, serial and parallel ports.

#4 Lisp:
-HedgeHog Lisp
-SBCL
-CLisp
-gambit Scheme and termite

#5 As much hardware, software and documentation support for the GNU
software radio as is possible:
http://gnuradio.org

#6 A question and a suggestion:
Are you accepting volunteer help?
Try asking the board manufacturers for borrowed sample boards to test
load Pyramid Linux and its drivers on.

Thanks,
Joe

[JohnC]

I am looking for any idea's for a new web interface, you are more than
welcome to contribute to the cause. Have you looked at the latest
version of wificonfig. I have been considering forking that to
pyramids needs.

John

[Marshall Crocker]

Take a look at http://www.polarcloud.com/tomato especially the
screenshots and videos at the top of the page.

I haven't looked at the latest version of wifiadmin but if the
screenshots on wifiadmin's webpage are of the latest, then it still is a
far cry from tomato's admin interface. I would suggest forking tomato's
admin interface if the author is ok with it. Otherwise m00nwall is
still a better choice than wifiadmin.

Marshall

[garlicsalt2]

I had added the module to /etc/modules. Thanks, these are the files
for which I was looking. I knew I had to edit some, but didn't know
which ones. It seems to be working now. Now, it recognises the phone,
but tells me "Data Service unavailable" on the phone's display.
Perhaps it is time to call Sprint and see about actually activating
the phone...
[Rhetorical statement]

As for console access, I had already made identical changes to /boot/
grub/menu.lst. Everything now goes to the console, except for the
login prompt - it is still going to Serial terminal.

Correction, WAS still going to the serial terminal... Just found the
solution:

cp /etc/inittab.standard /etc/inittab

then edit /etc/inittab to comment out the NC line. Otherwise, nocat
respawns, terminates, respawns, terminates, respawns, terminates, is
disabled by init for 5 minutes, respawns, terminates, ...

I also changed the baud rate to 19200 for the serial getty command, so
that I still have access there.

> > > > Thanks John- Hide quoted text -
>
> - Show quoted text -

[Val]

I have a couple of requests:

1) Could we clean out all the redundant, not used software and their
configurations? For example, there are something like three places to
configure ntp but only one is used. dnsmasq handles dhcp and dns
lookups, but dhcpd.conf is in /etc and not used. There are many more I
think.

2) Add a line to /etc/inittab and an rc.local script to make it easier
to configure systems to run user-written scripts on startup.

3) NTP typically never has a chance to set it's clock on boot because
it looks for an NTP server before network interfaces are up and
routing has a chance to resolve. A script to set the clock a few
minutes after boot would at least give nodes with a wireless
connection to shore a chance to get it right.

4) The hostap drivers used on the latest version of pyramid don't
support connection statistics in /proc/sys/net/ipv4/wireless (you get
all zeros). Support for these statistics have been around in other
implementations of the driver for a long time and should be easy to
incorporate.

5) I would greatly appreciate it if syslog were configured with a
strict file rotation/deletion policy to ensure the logs don't fill up
the system. It is extremely difficult to troubleshoot a system without
system logs.

6) Others have commented about the admin pages. My only comment is
that they are fragile. For example, if you leave a commented out
configuration in /etc/network/interfaces, the web page will often not
ignore it and cause much confusion and the need for a serial cable.

7) Finally, I'd like to see Pyramid available for other hardware than
just soekris boards.

Thanks for listening!!!

-Val

[C.J. Adams-Collier]

I'd also like to see an SNMP daemon stock on the device, since most pyramid hosts will be network devices, and it would be nice to be able to monitor them using the standard interface.

--
moo.

[Nicolas Jungers]

> > On Oct 24, 2:14 pm, JohnC <j...@techie.com> wrote:
> > > I am going to be working on updating Pyramid over time. I am looking
> > > for any input as what you the users would like.

I'm fairly new to Pyramid, and so much of the above suggestions seems
to be just fine for me. I'm working on a very small project (3 old
wrap 1E), and I had a very hard time to choose a wifi distro. At the
end I settled for Pyramid not because of sheer love but because the
others seemed even more unfit for my needs. So I have a few more
remarks/suggestions/questions. I apologize if I'm a bit rude in what
follows, it's not really my intend.

1) What is the rational for the ro/rw split? I perfectly understand
why part of /var are in ram, but I've a hard time to understand the
configuration split. I suppose that I'm not alone to issue a rw
command as soon as I log in to modify the configuration. The careful
testing of a configuration in ro mode before commiting it may save a
few CF cycle around the world, and even prevent a CF to die somewhere,
but I don't think it's worth the annoyance. I also suppose that the
period when most hectic changes happens is when on the bench where
it's no big deal to swap a dead or dying $5 CF. And the CF failure
I've experienced in the field haven't appeared to be related to write
cycles.

2) The code base. The rational for an Ubuntu release was certainly
very good, and the immutability of the system is what one want for a
shipped box. But still I wonder if it wouldn't be more exiting to
have a build system able to start from an arbitrary version of a major
distro instead of having to reconstruct one when the various component
start to drift away (kernel version, utilities...). I'm thinking more
of kind of portable variation of a distro, a bit like a Fedora spin or
a Debian blend. The idea is to have a branching which auto-magically
follows patches and need only to be ported to the new base distro once
in while. I quite understand
that "auto-magicallity" and porting to a new base involve a non
trivial amount of work. But I bet (shooting in the dark, really) that
the amount of work pays off in the long run.

3) Documentation. Hard to find, scattered. I'm taking notes of what
I'm doing and I plan to post it for review and re-use.

4) I've found a few annoyance an I still need to read some
documentation, but I'll post those in separately.

Thanks for reading, and please if you want to dismiss my point 1 and
2, point me to an explanation of my foolishness.

Nicolas

[Marshall Crocker]

> 1) What is the rational for the ro/rw split? I perfectly understand
> why part of /var are in ram, but I've a hard time to understand the
> configuration split. I suppose that I'm not alone to issue a rw
> command as soon as I log in to modify the configuration. The careful
> testing of a configuration in ro mode before commiting it may save a
> few CF cycle around the world, and even prevent a CF to die somewhere,
> but I don't think it's worth the annoyance. I also suppose that the
> period when most hectic changes happens is when on the bench where
> it's no big deal to swap a dead or dying $5 CF. And the CF failure
> I've experienced in the field haven't appeared to be related to write
> cycles.
>

While having a read-only filesystem should increase the life of a CF, I
personally prefer read-only to protect the integrity of the filesystem.
The pyramid image uses the FAT filesystem which means a power outage
while mounted rw could corrupt the filesystem. A journaling filesystem
such as ext3 is no good as it will most definitely wear out the CF
prematurely since all writes go through the journal file.

I don't know about everyone else, but once my router is setup I rarely
have to make changes to any files on the system. I think the benefits
of having a default ro filesystem outweigh the extra rw/ro commands
needed to make changes to files. You can of course change the default
mount to rw but I doubt pyramid will ever choose rw as default.

> 2) The code base. The rational for an Ubuntu release was certainly
> very good, and the immutability of the system is what one want for a
> shipped box. But still I wonder if it wouldn't be more exiting to
> have a build system able to start from an arbitrary version of a major
> distro instead of having to reconstruct one when the various component
> start to drift away (kernel version, utilities...). I'm thinking more
> of kind of portable variation of a distro, a bit like a Fedora spin or
> a Debian blend. The idea is to have a branching which auto-magically
> follows patches and need only to be ported to the new base distro once
> in while. I quite understand
> that "auto-magicallity" and porting to a new base involve a non
> trivial amount of work. But I bet (shooting in the dark, really) that
> the amount of work pays off in the long run.
>

Nontrivial indeed. If you want this level of
customization/control/flexibility, then checkout buildroot or a distro
that uses buildroot. buildroot is a set of scripts that will build your
own custom linux distro. It downloads source files for the toolchain,
kernel and all applications, builds them, and produces a bootable image.
I've been there, done that and I can tell you for me it wasn't worth the
hassle. The fact that pyramid is built on ubuntu 5.10 means if I need
an app not included, I just get it from the 5.10 binary packages.

Marshall