NanoBSD version installs are not flexible enough…
-
I wonder if there aren't some options to make the embedded disk images more universally useful
e.g.
a) why disable screen and keyboard instead of testing if screen and keyboard are present?
b) why assume a certain type of NIC instead of using whatever NIC is found, i.e. whatever driver is successfully loaded?Right now, it seems all centered around some ALIX board or whatever. I have e.g. a http://www.lannerinc.com/Network_Application_Platforms/x86_Network_Appliance/Desktop-Fanless_Appliances/FW-7535 device, and after starting the device with a 4GB CF card that I populated like this:
root# dd bs=8192 if=~/Downloads/pfSense/amd64/pfSense-2.0-RC1-4g-amd64-20110326-0121-nanobsd.img of=/dev/disk14 489230+1 records in 489230+1 records out 4007775744 bytes transferred in 433.982375 secs (9234881 bytes/sec)the system is stuck at a blank screen. Console terminal? None of my computers even have a serial port, maybe with some effort I might be able to get one of the out-of-production USB-serial adapters, and with some luck I might even find a cable somewhere for a price that doesn't reflect "person desperate to buy some legacy technology part".
In short, the idea to configure a device like that over a serial port is about as modern as asking someone to write configuration data to a 5.25" floppy disk.
With a tiny bit of smarts after an initial boot of an un-configured system it should be easy to get it going.
Right now, for a local system I'll dare putting a regular OS on a CF card, regardless of limited read/write cycles, because I have enough RAM (4GB) that swap will not be used except in exceedingly rare cases, configurations are easy to back up, and it's if need be quick to reinstall things from scratch onto a new CF card.
But the other unit is going to be a remote unit, and I can't risk anything there, because a failure will mean down-time of close to a week or a very expensive last-minute same-day flight to another location plus hotel, airport transfers, etc.So I need to get nanoBSD running somehow, but it's not quite clear to me how that's going to happen…
...I don't even know if the thing boots properly or not. So I have no idea if the disk image was written correctly, etc.NanoBSD is a great idea, but if it's so inflexible that it works only with very few devices, it becomes a non-option for most people.
Maybe there could be a way to have the NanoBSD image on the LiveCD. Then one could save a config on a USB stick, and an installer could first dump the disk image onto one USB drive, and then copy the configuration from another USB drive.
It would also solve the issue of how to write the NanoBSD images, because the LiveCD would know how to do that, and so the LiveCD would be the only thing that needs to be distributed aside from system upgrades on the server. -
Well just use supported hardware like the Alix boards or as you've said try using an usb to serial adapter…
-
You could also just mount the disk in another computer after you've written it to the CF and then moddify the config.xml to whatever hardware you use.
-
Well just use supported hardware like the Alix boards or as you've said try using an usb to serial adapter…
Let me rephrase then: the supported hardware is not powerful enough.
There's a nice little sweet spot in the price/performance/power-consumption tradeoff, and it changes rapidly as technology advances.
The supported hardware has been the same for at least the two years I've been following the project a bit. That's an eternity in computing. They likely consume about the same amount of power (since my Lanner can run fanless), but I get a 1.6GHz dual-core 64-bit chip with hyperthreading and 4GB RAM and six NICs in a tiny box.The supported boards aren't even near that league from what I can tell.
So either the supported hardware should see some upgrades to more current performance levels, or the initial setup should be given some extra smarts to make it more universal, which is a better, and longer-term solution.
Checking what drivers successfully load and base behavior on that, should not be that difficult, I hope, and it would solve this issue for many years to come and for platforms not even conceived yet.Anyway, don't get me wrong, I'm not being unthankful, I'm just pointing out what I consider a strategic improvement. Now, the number of uses of the nanoBSD version is limited, yet significant engineering time is likely invested in maintaining that branch. With a few minor changes, the field of platforms and users benefitting from that engineering investment could be greatly expanded.
-
If you want more power why not go with the full install? The embedded version is - like the name tells you - for small embedded devices…
-
If you want more power why not go with the full install? The embedded version is - like the name tells you - for small embedded devices…
The device I'm using is for embedded use. It has an on-board video, but you have to plug in a flat-ribbon break-out cable to use it, it's meant for setting things up, not for permanent use.
Similarly, it has an on-board CF card slot, so all the limits on how often CF memory should/can be rewritten still apply.
Just because the CPUs got more powerful over the last few years doesn't mean a system isn't designed for embedded use.
It's fanless, diskless, low-power. It just so happens to be a 1.6GHz, dual-core, hyperthreading 64-bit CPU with up to 4GB RAM. It's still an embedded networking device, that comes with 6 Gigabit ethernet ports.Powerful: yes
Low-power: yes
Fan-less: yes
Multicore: yes
64-bit: yes
Embedded: yesThese are no longer contradictions in terms. I still remember the first time a printer was using a 16-bit CPU as a printer controler, at a time when a lot of computers were still 8-bit machines with 64Kb RAM. The reviewers liked the printer, but were going on how wasteful it is to have a 16-bit CPU in a printer, when "nobody ever may even need a 16-bit CPU in their desktop."
Times change, but in this specific regards, pfSense hasn't kept up with the changes.
-
If you want more power why not go with the full install? The embedded version is - like the name tells you - for small embedded devices…
Safe to put full install on CF? (Still looking for specifics on what all is different/changed in nano to reduce writes to know how big of a deal it is)
I was sort of in the same boat as rcfa as the 'embedded' hardware was not enough so went the PC route but still wanted to use CF for storage and I used embedded version of pfsense to avoid writing too much to the flash card & wearing it out any faster than necessary. Although the board I used happened to have a serial port (not given these days), I had lappy w/ serial port (again not a given these days) & luckily had a null cable handy (happened to come across it while organizing basement recently), and it only took me a few minutes extra over installing from CD, I can see there is some overlap in needs between embedded & full.
I am not familiar with all of the details on what is actually different between the full vs embedded version of pfsense (besides obvious of freebsd vs nanobsd & it appears no swap part is used on nano) I can definitely relate to both sides. I too grumbled a bit about hassles of running through motions to do embedded (for starters the new reader on my main computer has no CF slot & writing IMG from Windows is PITFA to say the least and essentially foreign to doze world) it seems someone with a special setup can likely spare the effort to do the extra steps for installing embedded or possibly make changes to use full (like I considered using lappy hdd instead of CF). From what I can tell the main reason to use embedded version of pfsense is if the system has no way to run install cd (ie embedded) and secondary is fear of too many writes to flash drives/devices otherwise seems to make sense to use the installer.. (I will say I love the dual partition aspect of the embedded version! Just wish the boot delay wasn't so long but luckily don't reboot router too often.)
I will admit I swore a few times saying "WTF can't the installer do nano too?" and "WTH can't it just F'n assign some private IP(s) to the NIC's upon 1st boot when no config file is found like a router so I can setup via web/telnet/ssh instead of serial? I don't care WHICH one just give me an IP to connect to!!" but a few minutes later I had assigned nic's, assigned an ip to the lan card & was done with serial & did the rest via http and since I hope to not have to do initial setup very often life was good. :)
Bill -
I'm using Nano on embedded hardware with no problems at all. Of course I do have a laptop with a serial port so setup is no problem for me.
I would say though that most embedded hardware has a serial port (if not all) and that it expects to use it. Most rackmount stuff has a front serial port for this purpose.
On the other hand I can't really see why we can't have both. The Hacom images have both serial and VGA console output.It's worth pointing out that the NanoBSD install is not the same as embedded install from the CD. It sounds like that may be what you're looking for.
I don't really understand your NIC comment as I've used at least three different types as LAN no problem.
Steve
Edit: USB-RS232 leads are not expensive. ebay example
-
@Steve: If you were referring to my comment I mean it would be nice if nano/embedded didn't get vga/kb support to at least consider acting like most soho routers where pfsense uses detected NIC's rather than sit there waiting for setup via serial console.. (I realize that with particular hardware it does just that but I mean for everyone else without that particular hardware..) If it can detect at least 1 NIC it should be able to assign 192.168.1.1 (or such) to it & enable dhcp. Then maybe 99% of the time one does not need serial console (ports/cable/terminal sw) to do initial setup. There could be a published list of the order they are tried or one could simply plug in patch cord & see if they get an IP & if so they are good to go otherwise plug into the next NIC jack, rinse & repeat. (My earlier comment was to assign each a different private IP but I wonder if that is more trouble than worth)
And yeah one can buy parts up the wazoo to make things work (like usb to serial adapters) but to me ideally one should be able to use what they have on hand (Nic's & patch cords which we all have) & not need to worry about having things that are kind of rare these days or need to buy more stuff. (Ok many could argue the same could be said about almost any piece of hardware such as CF->IDE adapter etc but I am looking at it as how common the item is and how likely that item can be used for other things now & into the future. Serial has been pretty much dead for years other than rare oddball stuff. Back in the day serial ports were on all computers & we all had serial cables & adapters in our kit but it's 2011! lol)
Anyway, I for one don't really find it a big deal because as I said, it seems if one does embedded they likely have the stuff & know how to do it & everyone else will likely use installer cd & not worry about embedded but at the same time I can see the argument to try & make it simpler or at least more convenient too. Impossible to please everyone but sometimes there is a happy middle ground still. :)
Cheers!
Bill -
I was refering to question b) in the original post but I see what you mean now. If you're using dd-wrt or openwrt it boots up to a web interface by default and you only need serial access if something goes wrong or you have unusual hardware.
I guess it's just not a problem I've had so I didn't realise I might be a problem.
Probably more of a background thing. If you're used to rack mounted switches and routers, using a serial console for setup is not going to seem unusual. If you're a home user, however, then trying to find a null-modem cable and computer with a serial port is like working with antiques.You could always modify the config file on the CF card in advance so that the interfaces are pre-configured. Not that I've tried that. :-\
Steve
-
I was refering to question b) in the original post but I see what you mean now. If you're using dd-wrt or openwrt it boots up to a web interface by default and you only need serial access if something goes wrong or you have unusual hardware.
Are you suggesting that most standard NICs are automatically recognized and used in the embedded system? I was under the assumption that only the specific configuration of Alix and a couple of other boards as tested for, and everything else had to be configured manually from the serial console.
Well, maybe something went wrong with the writing in the CF card, but in my case nothing booted to a web interface, and I have rather common intel Pro networking (em0 - em5) so if that driver is supposed to be auto-detected, then the image must have been written wrong.
But if there's no issue with the CF card's file system, then it means even something as unexotic as intel Pro NICs aren't recognized without manual configuration.
-
@Steve: Yup pretty much boils down to what people are used to. I'm used to both camps so neither is foreign to me but I'd definitely rather plug in lappy via network cord, get assigned an IP & enter gateway IP into browser than deal with serial cable any day. :D Btw afaik the CF card is not fat/fat32/ntfs so very tough to edit the config file for the average Joe with doze. ;)
@rcfa: Based on watching the serial console info during bootup nanoBSD definitely detects supported nics (I have a realtek onboard & 3 Intel gigabits on daughterboard that are all detected & assigned interface names) but the problem is except for SPECIFIC hardware/nics those 'unrecognized' nics are just not CONFIGURED automatically so it is sitting there waiting for you to answer questions via serial console for the initial setup (the same you see when you boot the install cd on system with video/kb) rather than just loading some default private-ip setup like most/many routers do to let you do initial setup via ethernet.
-
Are you suggesting that most standard NICs are automatically recognized and used in the embedded system? I was under the assumption that only the specific configuration of Alix and a couple of other boards as tested for, and everything else had to be configured manually from the serial console.
What Bill said above! :)
All the NICs that are supported in the full install (mostly whatever FreeBSD supports) are supported under NanoBSD install it's just that you have to select one to be LAN from the serial console at first boot.Is there a possible security issue with having a web setup? At the moment you have to have physical access to the box to set it up, that could be seen as a good thing.
Steve
-
Is there a possible security issue with having a web setup? At the moment you have to have physical access to the box to set it up, that could be seen as a good thing.
Frankly, I could care less about the security issue. Here's why:
a) the chance of someone hacking my box in the few minutes between it being first booted and me getting into the web interface is pretty darn small.
b) if someone configures accounts, etc. before I get a chance to do so, there's a good chance I'll discover, and
c) most importantly: it's rather unlikely that the box will be hooked up to the public internet the first time around anyway, because it'll be hooked up to the laptop to do the configuration, so there'll be the famous air-gap to the public net until I'm done with the initial configuration.So, if the interfaces are recognized, I don't see why they are not all configured to grab an address through DHCP. Then whichever one is hooked up to the LAN will get an IP address, I can get in with the laptop, and a few minutes later I'd be good.
-
There's nothing antiquated about serial consoles, if you do much work with networks at all, you have what's needed (or you should). Every worthwhile managed switch and most all commercial routers require serial consoles. Hook up the serial console, assign the interfaces, done. At some point we may automatically assign interfaces, until then, a serial console isn't uncommon at all, don't act like it's a 5.25" floppy, go tell Cisco, HP, Juniper, etc. as they all require serial consoles.
-
@cmb:
There's nothing antiquated about serial consoles, if you do much work with networks at all, you have what's needed (or you should). Every worthwhile managed switch and most all commercial routers require serial consoles. Hook up the serial console, assign the interfaces, done. At some point we may automatically assign interfaces, until then, a serial console isn't uncommon at all, don't act like it's a 5.25" floppy, go tell Cisco, HP, Juniper, etc. as they all require serial consoles.
Well…
...it depends whom you're targeting. If I were to install pfSense for a large organization, I'd get a 1U rack-mount server, and even though in that environment there would likely be terminals etc. floating around, I wouldn't need them, because even if I want to go the solid-state storage route, I'd just put in a 2.5" SSD drive, install the full version, and call it a day.Only in an environment with wimpy enough networking demands, such as home use, would I even consider going with the embedded version. I want my hardware to be a bit beefier, such that's future proof, and also because I want to try to run freeSwitch on one of the two boxes (that one will have the full version of pfSense, but it will be local, so if the CF card wears out, I can within hours be back up and running again).
So the environment in which the embedded version is most likely going to be used is a branch-office, home-office or plain home use.I'm fairly involved with computers on a daily basis, this being my job, but outside my own private net, I'm not a network admin or working in a data center. Despite that, the last time I dealt with a terminal was when I installed as a gag a VT100 terminal in my bathroom, and hooked it up to my NeXT computer so I could joke with some friends about from where I just sent them the e-mail. That was when I was still in college, some 20 years ago. The last time I still used a serial connection for anything else was with a fax modem hooked up to the NeXT, too, which is also at least 15 years ago. Since then, everything has been USB, or network+ssh; I neither have UUCP nor kermit installed on any of my computers, even though they used to be some of the first things I put on any hardware after it came out of the box.
So in a home/office environment, particularly in a Mac OS X setup, serial communications are truly about as antiquated as 5.25" floppy disks. I know, in a data center that's very different, but why anyone in a data center would bother with the embedded version instead of running the full-featured version on a 1U server, would be beyond me.
Bottom line as far as I can see: without the network based OR console setup, a large segment of most likely nanoBSD users are going to have a much harder time than necessary. The network aspect isn't even the worst. If only the system could check for the presence of a video and keyboard device and not just blindly disable the console if these are present, that would solve all my issues, because my embedded device has a break-out cable to hook up screen and keyboard, exactly to make it possible to do initial setup, change BIOS settings, etc.
To use anything with a serial connection, I probably would have to spend as much money on USB-serial adapters, cables, etc. that I might be cheaper just replacing the CF card with a small e.g. 32GB SSD drive and installing the full version.
My point: if we're making using the the embedded version that difficult/expensive, then why even bother supporting it? Might just as well tell people to get a cheap SSD drive and run the full version.
-
You can still install the embedded version from the install CD which I believe has VGA console. You don't get the advantage of NanoBSD's backup slices.
You have to be able to boot from CD or USB which, for me, would be far more of a problem than using serial! ::)Steve
-
@cmb:
There's nothing antiquated about serial consoles, if you do much work with networks at all, you have what's needed (or you should). Every worthwhile managed switch and most all commercial routers require serial consoles. Hook up the serial console, assign the interfaces, done. At some point we may automatically assign interfaces, until then, a serial console isn't uncommon at all, don't act like it's a 5.25" floppy, go tell Cisco, HP, Juniper, etc. as they all require serial consoles.
Pfft, you must run with the big dogs then! :D Other than a freak thing last month where my cousin who sets up cell towers needed help with his USB->serial adapter working with some oddball programming utility, I hadn't touched serial since mucking with Tivo 1's to connect via PPP over the headphone serial port because the internal modem was borked! Anyway let's just say it isn't very often & when it has been has always been obscure equipment. I realize in some circles serial might be used daily still but the average Joe does not and many think you mean USB when you mention serial IF they even make that connection. And average computer person setting up a router likely knows what serial is but either doesn't have serial port, null cable, terminal sw (Win vista/7 don't even have hyperterminal anymore but then again almost need a 2k lappy to still have serial port lol), or has to big thru boxes tucked in the basement which was what happened in my case.
A big part is thanks to the Legacy Free PC 'standard' from like around 2000 (hard to believe that was 11 years ago!) which Dell in particular took a liking too, likely because it saved them money. And you know serial stuff has gone way of 5.25" floppies when stores don't carry the adapters/cables. Heck even rat shack site says web only for almost everything serial, and that is a whopping 5 things they happen to still sell. lol
Anyway as I said earlier, personally it ended up not being a big deal for me since I had the stuff but had I had not I would have swore a few times & installed the full version from CD & got over it. Of course hoping that my CF card didn't get wore out too quickly. My comments were meant merely to agree it would be helpful if the embedded/nano version could be more user friendly in initial setup not to debate if serial was dead or not. ;)
Bill -
@cmb:
There's nothing antiquated about serial consoles
It could just be me that's antiquated! :(
It never fails to amaze me that some people have actually stopped using email entirely in favour of facebook. Those same people probably don't use serial that often. :PIs there some big problem to having both serial and CGA console? Perhaps a boot time parameter could be used to switch consoles?
Steve
Edit: Ironic typo left in for effect. :D
-
RS-232 ports are getting a bit harder to find these days. I kept an old laptop with a built-in COM port around for years, but finally gave up when its battery became useless and I couldn't read the screen very well due to CCFL aging.
It does seem like some sort of compromise between a full install and the existing Embedded build would be useful. Maybe a full-featured build based on NanoBSD would work.
