rpi-config (Clone of raspi-config) Base additions.

This sounds like a great Idea.  I might test this if I get time.

First of all welcome to the "other forum," and disregard the kind of treatment you get from the red and green minions in the "official forum," that is standard practice and behaviour when somebody tries to suggest something different, perhaps not with the best terms and solid arguments, where a word out of place may directly put you on the meat grinder and in path to become one more "concern troll."

I've read the thread and I've to give more thought to your suggestion which I consider valid, while DHCP is a good option for an almost Plug-n-Play quick config, having the option to assign a static IP address is also a good option.

I'm casually dealing with a similar situation testing the recently released Fedora Remix image where there is no login enabled via the UART, the framebuffer configuration for the analog video output does not work properly with my monitor where there are portions of the screen I can't see.

Fortunately the image includes dhcp and sshd enabled, and it recognized the wireless transceiver for the keyboard I was using. After several tries I was able to complete the first boot which includes setting the root password and a user/password (to make it more difficult you can't set easy simple passwords, seems that the security level is set to freaking high.) Then after finding what IP address was assigned to the board via DHCP I was able to ssh to the board and finish up and complete the configuration I desired.

It would have been great, first if the serial interface had a getty enabled for login via UART and a configuration option to set DHCP or a static IP address.

I'm sure that if I tell the Fedora folks about it will have a different kind of reception that if you try to touch the sacrosanct cult based Raspbian.

Not sure if it has to be a "top priority" but it is not a bad suggestion. I'll take a look and give a try at your code.

-J

My take on this issue is as follows:

• Static IP provides a standalone configuration, and hence it is a necessary foundation for all networking.  After all, nothing else in the local network may be working at all, and you certainly can't rely on a DHCP server being present and configured correctly.

• Dynamic IP is a more complex form of configuration and assumes that the local networking environment has already been set up with DHCP and is working properly.  If this is the case then adding a new node is transparent for the user, but if DHCP is not available then the user has no path forward other than static IP.

Since both requirements and/or situations are common, they should both be configurable at installation time.  If it is possible to provide only one of these two, then it must be static IP, because that is foundational for IP networking and dynamic is not.

[Dynamic IP is really just static IP config performed by a client-server pair on every boot or lease renewal.  Once DHCP has done its work, you just have static IP on your host until the next boot or as long as the lease lasts.  Clearly static IP is the foundation, and dynamic is layered on top of it.]

On the educational side of the argument, DHCP hides how basic IP networking is configured, and hence its educational value is actually negative.

Morgaine.

but if DHCP is not available then the user has no path forward other than static IP.

I take slight issue with that, there's always RFC3927 - 169.254.x.x autoconfigured link-local addresses with mDNS and DNS-SD.

Yes, that stuff makes me tear my hair out whenever I encounter it, but it is another option.

Or try IPv6, fe80: link local addresses, Stateless Address Autoconfiguration, Router Advertisment and/or DHCPv6 combined with privacy addressing that changes your IP every so often.  Lots to learn from an educational perspective

After several tries I was able to complete the first boot which includes setting the root password and a user/password (to make it more difficult you can't set easy simple passwords, seems that the security level is set to freaking high.)

this sort of stuff really annoys me. it's really out of place on a device that's deliberately designed to be unkillable and easily recoverable with a simple re-write of the sd-card.

How many of the people using these will be used to windows home edition with fast-user switching and no concept of passwords. Putting up barriers just isn't a good start for an educational device.

Take in accuont that the Fedora Remix image is not yet ready for prime time and it is out of the hands of the RPF so I expect that sooner or later the Fedora folks will make it easier, so far the current version is kind of cryptic as an educational version.

-J

Greetings Morgaine

What gets me is asb did not understand in the first place when he wrote raspi-config. It really does show a lack of peer review within "the foundation".

The fact he added  over clocking is also a very poor decision. Advanced features are best seperate so as to not muddy the waters.

I signed up for the "official" forum in March and did not post until August. That's a lot of reading.

It is "the foundation" that needs the support of developers.

Anyway the additions have been made and put in the public domain. All I can do is wait and hope they do the right thing.

Although credit for the two days of work is not a big issue standard practise is to give credit where credit is due.

raspi-config is the first thing a new users sees. It is actually one of the more important pieces of script in a distribution.

What "the foundation' does not know is who is watching, who they talk to and how it effects "the foundation".

Regards

Peter

Take in accuont that the Fedora Remix image is not yet ready for prime time

IMHO, it probably never will be. It's my understanding that Seneca is actually a Further Education Institution, so you'd expect them to be exactly the right sort of people to put together a decent educational distribution.

Set dns. Change the dns server settings.

I didn't look too closely, but you still appear to use 8.8.8.8 as default DNS server.

Personally I find having a default like that highly obnoxious. If I don't set one, or if my DHCP server doesn't provide one, then that's deliberate and there shouldn't be one configured.

Don't take that personally - I realise that was part of the original configuration and not something you've done, but given your post about it in the other thread I'd expected you to have removed it too

On the whole topic of using DHCP as a default, I wonder how many of them have a broadband router that came configured by default to get it's LAN side address from DHCP ?   Or, as with most, did it come with a pre-configured well known static IP address (192.168.0.1 usually).

Two other things to add: As you've found suggestions, constructive or otherwise, tend to fall on deaf ears if they don't get you outright banned, the RPF has their way of thinking and nothing apparently will dissuade them from it - I'm actually fine with that. And we don't stick to the topic over here

I have no control over the defaults Raspbian (dns) has however I have allowed it to be set to something different in my clone.

My modem is 192.168.255.254 others 1.1 What my script show is up for discussion. You say 0.1 and you may be right.

I also have no control over my suggestions being added to the official distribution where these default get set.

By releasing what I have done in the public domain it is at least out there.

I have no plans of doing any more to it unless someone finds a bug.

My tests say it works as expected in a default install situation.

Of course there are many different setups for hosts for instance but that is beyond the scope of the software.

I do not think it is meant to be a general setup tool and carries a warning to that effect.

The name rpi-config or any variant is up for grabs. For someone interested it would be a good way to have a continued interest in the way of the Penguin.

For me, I just say it as it is and back it up with code to address the issue.

I do not think I am under any obligation to do anything more.