Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixes and improvements #27

Open
wants to merge 13 commits into
base: master
Choose a base branch
from
Open

Conversation

jjakob
Copy link

@jjakob jjakob commented Feb 17, 2021

This fixes some bugs I ran into and adds some new features. See the commits for more information.

@jjakob jjakob force-pushed the gbpc2_fixes_rebase branch from ca375d7 to 1f6c0cb Compare February 17, 2021 20:12
The initramfs didn't contain dropbearkey so host keys weren't generated.
Use -R instead. Should be in all dropbear versions from jessie onward.
@neilbrown
Copy link
Owner

Thanks for the patches....
However I really don't like the excessive quotes. This is C. Quotes don't say "this is a string" - because everything is. Quotes say "this needs to be protected. So quoting a constant string with no spaces or special characters like

echo "UNKNOWN"

is pointless.

Also with variable assignment there is no wildcard or IFS interpretation so

proc=readlink $prog

does not need extra quotes ... except maybe around the "$prog".

It is always appropriate to quote a variable when it appears in command like arguments (unless you want spaces to be processed), but most other places where you have added quotes, I'd really rather not have them.

Also, you have added E: W: I: in front of lots of messages, without any explanation in the commit message.
I'm not completely against these annotations, though I really prefer to see "ERROR" when there is an error, and "WARNING" when there is a warning.

Your other changes that change the behaviour, like the dropbear changes and the debian mirror configuration do look useful. If you could provide a pull request that just, I would appreciate it.
And if you really want to include lots of quotes in the code you submit, then I won't object. I just don't think there is any value in adding lots of quotes to code that isn't wrong.

Thanks.

@jjakob
Copy link
Author

jjakob commented Feb 20, 2021

I add quotes around everything, even if not technically needed, out of habit. I agree quotes around constant strings are pointless. Others I add due to security, to prevent possibly malicious code getting executed (ACE). Since using a remote gnubee system as the source of many variables this is also possible if the system ssh connects to a different host or that host is compromised. I know, it's very unlikely in this case as the environments are controlled, but more quoting in the right places doesn't do any harm.

I'll go through it and see what I can do.

Copy link
Contributor

@vincele vincele left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

EDIT: comment removed, since I made a more complete review...

Copy link
Contributor

@vincele vincele left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Refrain from doing cosmetic changes (whitespace, comments, etc.) in the same commit as semantic changes, this makes them harder to review.

When you do a series of commits, put the cosmetic ones last, so that they can be easily skipped, as they often are a matter of taste.
So the semantic changes can be merged anyways, separately from the controversial ones.

It's a shame to see such contributions being ignored or postponed upon cosmetic discussions, as there are good things that could go in easily.

For this series to be (partially-) mergeable, I'd suggest at least splitting some commits, those that are mixing different things.
And maybe also splitting the whole PR into smaller logical pieces with one subject only.

Keep the cosmetical commits at the end of the serie(s) so that they don't block the whole PR.

I don't know if you're still interested in following up on this, just say so.

In any case, thanks for your work.

fi
dropbear

# -R to generate new host keys on each boot
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this comment accurate ?

Reading the man page @ https://manpages.org/dropbear/8
I'm not sure I can tell if it'll only be generating keys if they are absent or if it will (re-)generate keys at each invokation.

I've not tested, sorry, just asking while looking at your PR...

@@ -16,7 +16,7 @@
mp=/tmp/newroot
default_debian_suite=buster
default_debian_mirror="http://httpredir.debian.org/debian"
include_packages="vim,openssh-server,ntpdate,cron,locales,udev,fake-hwclock,mtd-utils,ca-certificates,apt-transport-https,vlan"
include_packages="vim,openssh-server,ntpdate,cron,locales,udev,fake-hwclock,mtd-utils,ca-certificates,apt-transport-https,vlan,bash-completion,less,man-db,manpages,dbus"
Copy link
Contributor

@vincele vincele Dec 3, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd separate that into 2 commits, one for the fix, maybe adding a reference in the commitmsg to the "timedatectl bug" that is being fixed.

And another commit for the "useful" stuff that may be a matter of taste (i.e.: you prefer minimalistic or with batteries included)

initramfs/config Outdated
@@ -16,7 +16,7 @@
mp=/tmp/newroot
default_debian_suite=buster
default_debian_mirror="http://httpredir.debian.org/debian"
include_packages="vim,openssh-server,ntpdate,cron,locales,udev,fake-hwclock,mtd-utils,ca-certificates,apt-transport-https,vlan,libnl-3-200,libnl-genl-3-200"
include_packages="vim,openssh-server,ntpdate,cron,locales,udev,fake-hwclock,mtd-utils,ca-certificates,apt-transport-https,vlan"
Copy link
Contributor

@vincele vincele Dec 3, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was asking myself a question about those version-specific packages, wrt your change about the default debian version to be used for the rootfs.

So is this removal because "they are not needed in the new debian version any more" or is it something else ?

In fact, I only ask to add a little bit more details to the commit msg, the actual patch may be fine.

@@ -14,6 +14,8 @@
# add leds udev rule

mp=/tmp/newroot
default_debian_suite=buster
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How is that related to the other change in config.sample:
GNUBEE_DEBIAN_SUITE="stable"

@@ -72,9 +72,9 @@ gnubee_defconfig() {
case $mach in
"" | defconfig ) # guess
if mach=`gnubee_model`; then
echo Using config $mach
echo "I: Using config $mach"
Copy link
Contributor

@vincele vincele Dec 3, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm no fan of those one-letter prefixes, what does the "I" stand for ? "E" or "W", I can guess... But I also prefer the longer, more explicit ones.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I: is info. Doing this is consistent with the messages that the debian installer produces so it certainly makes sense for the messages generated by the "config" script.
It is less obvious that it would be appropriate for the gbmake script, but maybe it does and I'm certainly open to making it clearer.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK debian consistency is an accepted excuse ;-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants