EC2 instances are normally launched with an SSH public key specified,
which is then used for logging in (by default, as 'ec2-user'). Having
ChallengeResponseAuthentication enabled (as FreeBSD's default sshd_config
does) has no functional effect in a new EC2 instance, since you can't log
in using a password until a password has been set -- but having this
enabled results in alerts from automated scanning tools which can detect
that sshd advertises support for keyboard-interactive logins (since they
can't detect that accounts have no password set).
EC2 users who want to use passwords to log in to their instances will need
to set 'ChallengeResponseAuthentication yes' in FreeBSD 12.0 and later.
Discussed with: gjb, gtetlow, emaste, des
Requested by: Amazon
X-MFC: No
Relnotes: ChallengeResponseAuthentication is turned off by default in
Amazon EC2 AMIs.
copied from the build host. It is renamed to /etc/resolv.conf.bak
on boot, so never used anyway.
Noticed by: peter
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
This changes the build OBJDIR from the older style of /usr/obj/<srcdir> for
native builds, and /usr/obj/<target>.<target_arch>/<srcdir> for cross builds to
a new simpler format of /usr/obj/<srcdir>/<target>.<target_arch>. This
new format is used regardless of cross or native build. It allows
easier management of multiple source tree object directories.
The UNIFIED_OBJDIR option will be removed and its feature made permanent
for the 12.0 release.
Relnotes: yes (don't note UNIFIED_OBJDIR option since it will be removed)
Prior work: D3711 D874
Reviewed by: gjb, sjg
Discussed at: https://lists.freebsd.org/pipermail/freebsd-arch/2016-May/017805.html
Discussed with: emaste
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D12840
immediately available on instances which are running without internet
access (or which can't rely on firstboot_pkgs to install it for some
other reason).
Note that this agent is not enabled by default; to enable it, add
amazon_ssm_agent_enable="YES" to /etc/rc.conf, e.g., by placing the lines
>>/etc/rc.conf
amazon_ssm_agent_enable="YES"
into the EC2 user-data. In addition to being enabled, the agent requires
keys to be provided via IAM Roles; users are encouraged to be very careful
in using this functionality due to the inherent vulnerability in the idea
of providing credentials via a service accessible to any process which can
open an HTTP connection.
Requested by: Amazon
No objection from: re@
Relnotes: FreeBSD/EC2 AMIs now include the Amazon EC2 Systems Manager
(SSM) Agent.
A recent bug in security/sudo causes segmentation faults when
the system is not configured with a hostname, which causes issues
with some virtual machine setups, notably Vagrant. Set the default
hostname to the output of 'uname -o'.
Submitted by: Nicholas Fiorentini
Sponsored by: The FreeBSD Foundation
build on arm/armv6 images.
Pointyhat: gjb (myself)
MFC after: immediate
MFC note: releng/10.4 has broken because of this
Sponsored by: The FreeBSD Foundation
virtual machine images and embedded images, similar to what is
done when extracting base.txz to the target root filesystem in
an new installation.
Noticed by: marius
Tested with: head@r323729
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Engine (GCE) images with an updated version of Google's tools.
PR: 221714
Submitted by: helen _dot_ koike _@_ collabora_dot_com (original)
MFC after: 5 days
Sponsored by: The FreeBSD Foundation
- Rename chroot_arm_armv6_build_release() to chroot_arm_build_release()
and make it hardware agnostic (such as armv6 -vs- armv7 -vs- arm64).
- Evaluate EMBEDDED_TARGET differently so release/tools/arm.subr can
be used for arm/armv6 and arm64/aarch64.
- Update comments and copyright.
In release/tools/arm.subr:
- In arm_create_disk(), change the default alignment from 63 to 512k,
fixing a boot issue on arm64 and EFI. [1]
- Update comments and copyright.
Add a RPI3 configuration file, pieces obtained from Crochet.
Obtained from: Crochet [1]
MFC after: 5 days
X-MFC-Note: maybe
Sponsored by: The FreeBSD Foundation
install to prepare an AMI image. This can be used to create a ZFS AMI disk
image using a virtual machine.
Change ec2.conf to use the pkg tool from a chroot rather than trying to
bootstrap it and fail from the livecd readonly filesystem.
Reviewed by: gjb
- Speeds up the boot process by disabling sendmail.
- Allows an user to ssh as root with a public key.
- Make ssh(1) respond faster by disabling DNS lookups.
- Enable DHCP on the vtnet(4) interface.
Note: The CLOUDWARE list has not yet been changed to include the
OpenStack target by default yet.
Submitted by: Diego Casati
PR: 215258
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
running on EC2. Due to improvements in EC2, the performance penalty which
was present on some EC2 instances no longer exists, and enabling this
feature now consistently yields ~20% higher throughput with equal or lower
latency.
Reverts: r286063
Approved by: re (gjb)
MFC after: 2 weeks
Relnotes: Improved disk throughput on EC2
30m isn't enough for pkg anymore to extract packagesite.txz.
40m is fine for now but let's take a safer way as we don't know when pkg will need more.
Reported by: many
Approved by: re (gjb), andrew (mentor)
on performance, especially with SD cards on certain SoCs.
Requested by: trasz
Discussed with: ian, kientzle
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
A stray trailing space snuck in with one of the recent
changes, making r290550 and r290573 effectively no-op.
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
issues on some EC2 instance types. Users may want to experiment with
removing this from loader.conf and measuring the performance impact on
the EC2 instances they are using.
- pkg(8) cannot be removed before subsequent reinvocations
- The PKG_CACHEDIR cannot be cleaned after the repo*.sqlite
has been removed
- pkg(8) cannot be removed as a precursor to any of the other
steps involved here
MFC after: 3 days
X-MFC-With: r285722
X-MFC-Before: 10.2-{BETA3,RC1} (whichever happens next)
Sponsored by: The FreeBSD Foundation
The true cause of the missing UFS/MSDOSFS labels has been
identified, and only affects stable/10 at the moment.
An request for commit to stable/10 will be pending RE approval
after this commit.
MFC after: 1 day
X-MFC-Note: never
X-MFC-Never: r285018, r285019, r285076, r285078, r285082
Sponsored by: The FreeBSD Foundation
the symlink from loader.rc.sample.
Fix paths relative to the CHROOTDIR.
MFC after: 3 days
X-MFC-With: r285076, r285078
X-MFC-Before: 10.2-BETA1
Sponsored by: The FreeBSD Foundation
UFS/MSDOSFS label issues on FreeBSD/arm builds, however
the real problem was addressed in r285076, which is due
to two separate issues, unrelated to md(4) stale device
existence.
MFC after: 3 days
X-MFC-With: r285076
X-MFC-Before: 10.2-BETA1
Sponsored by: The FreeBSD Foundation
FreeBSD/arm builds. The problem stems from the loader.rc file
not existing, as well as geom_label not being loaded at boot.
For now, add the geom_label_load entry to loader.conf, and
symlink loader.rc.sample to loader.rc, both of which allowed
my BeagleBone Black to boot fine with a UFS label reference in
fstab(5).
MFC after: 3 days
X-MFC-Before: 10.2-BETA1
Sponsored by: The FreeBSD Foundation
cannot possibly exist within the chroot(8) before the target
filesystem actually exists.
MFC after: 3 days
X-MFC-With: r285018
Sponsored by: The FreeBSD Foundation
written to disk with newfs(8) and newfs_msdosfs(8).
When iterating through snapshot builds in serial, it is possible for
a build failure to leave stale md(4) devices behind, in some cases, they
could have a UFS or MSDOS filesystem label assigned.
If the md(4) is not destroyed (or not able to be destroyed, as has
happened recently due to my own fault), the filesystem label that
already exists can interfere with a new md(4) device that is targeted to
have the same label.
This behavior, although admittedly a logic error in the wrapper build
scripts, has caused intermittent reports (in particular with the armv6
builds) of missing UFS/MSDOSFS labels, causing the image to fallback to
the mountroot prompt. This appears to only happen when the backing
md(4) device is destroyed before the calling umount(8) on the target
mount, after which the UFS/MSDOSFS label persists.
The workaround is this: If EVERYTHINGISFINE is set to non-empty value,
check for an existing ufs/rootfs and msdosfs/MSDOSBOOT filesystem label
in arm_create_disk(), and rm(1) them if they exist.
The EVERYTHINGISFINE variable is chosen because it is used in exactly
one other place - release/Makefile.mirrors - and there are big scary
warnings at the top of that file as well that it should *not* be used
under normal circumstances. This should not destroy a build machine
that also uses '/dev/ufs/rootfs' as the UFS label, and I have verified
in extensive local testing that the destroyed label is recreated when
the md(4) is unmounted/mounted, but this really should not be enabled
by anyone.
Having said all that, I absolutely *do* plan MFC this to stable/10 for
the 10.2-RELEASE cycle, as so far, I have only observed this behavior
on stable/10, but this is a temporary solution until I can unravel all
of the failure paths to properly trap them.
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
machine images to the Google Compute Engine platform.
By default, gcutil/gsutil requires an Oauth2 login generated
from a URL that must be opened in a browser, a verification
code copied back to the terminal from which it was invoked,
etc., etc., making it near impossible for automation.
I've hacked together an evil solution to work around this,
so unless GCE_LOGIN_SKIP is set to a non-empty value, this
Makefile will not do anything useful.
As a result of this commit, remove the gce-package.sh script
that was never, nor will ever be, used.
MFC after: 3 days
X-MFC-Note: (hopefully)
Sponsored by: The FreeBSD Foundation
Remove the Azure-local vm_extra_create_disk(), since we no longer
need qemu-img to convert the final VHD image to an Azure-compatible
format.
Although the waagent utility is installed from ports, create the
symlink to /usr/sbin, pending investigation on where this is
hard-coded, so it can be reported upstream. In the meantime, this
is good enough.
MFC after: 3 days
X-MFC-Needs: r284269, r284270, r284271, r284655,
r284656, r284657, r284658, r284659
X-MFC-Note: Required for 10.2-RELEASE, marcel@ has
implicit approval for the required changes
Sponsored by: The FreeBSD Foundation
