[HN Gopher] Amazon Linux 2022
___________________________________________________________________
Amazon Linux 2022
Author : gtirloni
Score : 90 points
Date : 2021-11-25 17:36 UTC (5 hours ago)
(HTM) web link (aws.amazon.com)
(TXT) w3m dump (aws.amazon.com)
| staticassertion wrote:
| Looks interesting. SELinux by default is certainly a win, it
| seems that Linux has finally hit a tipping point where SELinux is
| a reasonable option (ie: someone else is going to do the work for
| you).
|
| Unfortunately I'm just way more used to debian based systems, and
| I feel like having a mismatch in production would just lead to
| friction.
| jlawer wrote:
| RHEL running with SELinux enabled has been a thing since I
| worked at Red Hat 12 years ago, and Amazon Linux 2 was based on
| a CentOS upstream that had the capability of running in that
| way. All certification had to happen with SELinux enabled, and
| any distro provided service was setup to run with full
| restrictions, and it was the default on for all Professional
| Services work.
|
| However it became a problem once you used 3rd party software as
| step 1 of most install guides was to disable SELinux.
| takeda wrote:
| In RedHat or CentOS it was enabled by default as well. The
| problem was that if you installed custom software (not packaged
| by the distro) you had two options:
|
| - create and install SELinux rules for it
|
| - disable SELinux
|
| Unfortunately most did not bother to learn how to do the first
| option so they went with the 2nd option.
| saurik wrote:
| Why do people choose Amazon Linux over, say, an Ubuntu LTS?
| Shadonototra wrote:
| I can see linux eclipsing all the current OS's, it already
| happened with smartphones, IOTs and the other little things (i
| forgot how they are called)
|
| Only remaining piece is the desktop segment
|
| macOS has a unix environment, so it'll stay relevant (for how
| long?)
|
| windows has WSL, it's slow, i don't see myself using it since the
| host OS is a giant piece of shitty crap
|
| MS missed a chance with Win11, they could have went full steam
| ARM with a Linux Distro, 100% native Android support, 100% cloud
| native support, 100% unix support as a host OS, i wouldn't use it
| myself because i despise the company and its culture, but i can
| see potential, and i smell a huge missed opportunity
|
| Amazon it getting it right, even thought it's exclusively
| targeting for cloud usages
|
| Marketing wise it's great and consistent with their offering
| willbw wrote:
| For Linux to conquer the desktop you'd need for it to beat out
| Windows or Mac for market share. For it to do that you'd need
| it to be have competitive usability for everyday people, and
| this is still far off. When I use my linux box at work I have
| to google for things like, "how do I enable this resolution for
| my monitor which isn't showing up" and then punch in a bunch of
| commands into the terminal.
|
| The advantages of windows and mac these days are that a lot of
| stuff 'just works' and secondly that due to their 20-30 year
| history their desktop application ecosystem is much richer and
| also much more widely used. User interfaces are also more
| friendly in general.
|
| There's no technical reason why these faults cannot be
| overcome, but there are significant hurdles in getting a third
| OS to gain major market share from the incumbents MS and Apple.
| The reason they have market share in servers is because the
| experience is better to develop on and it is free. The reason
| they have market share in mobile is that it was free and Google
| could build on top of it, and secondly that mobile was a brand
| new market so there were no incumbents with decades of history.
| I don't see those conditions replicated for desktop, especially
| when you consider that desktop is in decline and therefore less
| attractive to spend capital on.
|
| If you want to make Ubuntu as nice as MacOS I think you need a
| private company willing to spend money and time in a concerted
| effort to get it to that point, which IMO won't happen.
| Icathian wrote:
| While I would love for this to happen, I just don't see it at
| all.
|
| There are literally millions of Windows workstations or laptops
| across corporate campuses in the US, because at the end of the
| day what 95% of white collar workers need to do their jobs is
| MS Office and *maybe* one industry-specific LoB app.
| charcircuit wrote:
| Isn't MS Office a web app now?
| mixmastamyk wrote:
| Yes, and considering the google office, that percentage is
| a lot lower currently.
| rch wrote:
| Last I checked, WSL wasn't available for Windows Server,
| unfortunately.
| cpach wrote:
| It is now! https://docs.microsoft.com/en-
| us/windows/wsl/install-on-serv...
| my123 wrote:
| WSL1 only, not WSL2.
| paranoidrobot wrote:
| What's your use-case for WSL on Windows Server, if you don't
| mind me asking?
| shaicoleman wrote:
| TLDR:
|
| * Will be released on a predictable schedule every 2 years,
| supported for 5 years. Minor releases every quarter.
|
| * GA will be based on Fedora 35. Preview is currently based on
| Fedora 34
|
| * There's no official statement regarding compatibility with
| Fedora packages
|
| * SELinux will be enforcing by default
|
| * Kernel will be a kernel.org longterm version, not the Fedora
| one
|
| * VM images/docker containers will be officially available when
| GA. For now you can download images unoffically [1]
|
| * Unofficial ETA is Q2 2022. For reference, AL2 is currently
| officially supported until June 30, 2023.
|
| 1. https://news.ycombinator.com/item?id=29344927
| chronogram wrote:
| You make no mention of it being a rebuild of RHEL 9 beta, so
| are they making their own EL based on F35 or is it based on
| RHEL 9?
| shaicoleman wrote:
| It's not based on RHEL. They're making their own distro from
| Fedora.
| rubyist5eva wrote:
| An LTS distribution based on Fedora (and NOT RHEL) is something
| I've been wanting for a long time, but I don't think this is
| really gonna be for the non-cloud general use case?
|
| Welp, better luck next time.
| vosper wrote:
| Perhaps someone could give me some advice?
|
| I work alongside a small team maintaining quite a lot of machines
| on AWS. They're struggling (IMHO) to manually apply all of the
| security patches their scanning tool identifies. My theory is
| that Amazon Linux gets patched frequently, and so they'd be
| better off spending time normalizing our EC2 infra so that every
| instance is running Amazon Linux, and then work on an easy
| rollout mechanism to deploy the latest version.
|
| Has anyone got any thoughts on this? It wouldn't obviate the need
| for patching completely, but I feel like AWS is already doing
| some of this work for us, so we should take advantage.
| rusteh1 wrote:
| Yes, one of the core benefits of a provider like AWS is that
| they provide tooling to treat individual instances as immutable
| entities that you simply replace without any interruption to
| your users. You should focus on expressing the infrastructure
| as code and using mechanisms like ASGs to roll out new
| instances based on the latest Amazon provided AMIs.
| windowsworkstoo wrote:
| Yep we do this, works good - you can either trigger a server
| refresh from SNS (AWS notifies you of certain AMI updates) or
| we just rebuild our underlying fleet each week with the most
| current AL2 AMI
| voidfunc wrote:
| Every mainstream upstream Linux vendor is continuously pushing
| updated AMIs. It shouldn't really matter whether you solve this
| with Ubuntu or Amazon Linux or RHEL/CentOS.
|
| Sounds like you need a better process / automation for rolling
| updates. Either continuously rebuilt golden images or rolling
| security patches, or turning on your distros unattended upgrade
| mechanism could be solutions depending on your environment.
| gtirloni wrote:
| If you can, definitely standardize on as few distros as
| possible. It'll make applying patches (and learning when things
| go wrong, because they will) much easier.
|
| We used to have all sorts of distros that people just felt like
| using without worrying about their maintainability. We kept
| fighting fires to keep everything running. Once we standardized
| on a single distro (CentOS at the time), everything started
| working much more smoothly. We could have picked Debian,
| Ubuntu, it doesn't matter.
|
| That being said, Amazon Linux 2 is pretty well maintained. Most
| things (all?) that work on RHEL, will work on it. You may need
| to use 3rd-party repos if you want really newer stuff (eg. PHP)
| but that's inherent to such LTS releases. That situation is
| expected to improve with the improvements that adopting Fedora
| brings in AL2022 but I need to catch up.
| LilBytes wrote:
| For those few AMI's that are long lived, AWS SSM Patch Manager
| is your friend. Naturally take care to roll out patches in a
| rolling block, you don't want to apply a broken patch
| everywhere in the same day :)
|
| https://docs.aws.amazon.com/systems-manager/latest/userguide...
| belval wrote:
| I second this, we use it to manage a bigger fleet with a few
| hundred machines. One thing to keep in mind though is that it
| will not apply kernel updates (as those require a reboot) so
| you still need to account for it.
| mark_l_watson wrote:
| On AWS, I always now use Amazon's Linux distro. They also
| maintain their own version of OpenJDK.
|
| As skeptical as I am about huge tech corps like Amazon, Google,
| etc., I have to admit I enjoy being their paying customer - nice
| experience. I find GCP and AWS a pleasure to use.
| m0zg wrote:
| How do you develop for it though? Do you install it locally as
| well? Or do you only do interpreted languages and/or Java? I
| suppose Go would work across distros also (because it doesn't
| use libc), but that's all I can think of.
| throwaway984393 wrote:
| You should just develop your apps in/with/for containers. The
| container contains all the dependencies for your app. This
| way you never have to think about the host OS ever again;
| your app "just works" (once you hook up the networking,
| environment, secrets, storage, logging, etc for whatever is
| running your container). That sounds like a lot of extra
| work, but actually it's just standardizing the things you
| should already be dealing with even if you didn't use
| containers. The end result is your app works more reliably
| and you can run it anywhere.
| [deleted]
| takeda wrote:
| > You should just develop your apps in/with/for containers.
| The container contains all the dependencies for your app.
| This way you never have to think about the host OS ever
| again; your app "just works" (once you hook up the
| networking, environment, secrets, storage, logging, etc for
| whatever is running your container). That sounds like a lot
| of extra work, but actually it's just standardizing the
| things you should already be dealing with even if you
| didn't use containers. The end result is your app works
| more reliably and you can run it anywhere.
|
| This is a false sense of reproducibility. I encountered
| cases where container worked well on one machine and
| crashed or had weird bugs on another one.
| fl0ki wrote:
| This is true, but people focusing on only these benefits
| often miss the fact that they still have to update the
| image contents and re-deploy as soon as security patches
| are available.
|
| This is like updating the direct dependencies of your
| service itself (e.g. cargo audit -> cargo update) but
| anecdotally I'm seeing many people neglect the image and
| sometimes even pin specific versions and miss potential
| updates even when they do later rebuild it.
|
| We take unattended upgrades for granted on Debian-based
| servers, and that will likely help the Docker host system,
| but I'm not aware of anything nearly as automated for
| rebuilding and redeploying the images themselves.
|
| It could be part of your CI/CD pipeline but that in itself
| is a lot of extra setup and must not be neglected, and it
| must make sense, e.g. pin in a way that will still pick up
| security patches and have a dependency audit as part of
| CI/CD to report when the patching hasn't been enough (e.g.
| due to semver constraints).
| dharmab wrote:
| Some of us are systems/infrastructure engineers who have to
| build the intermediate layer. You can't just lay a
| dockerfile on top of a kernel and hope the system learns
| how to run it by osmosis.
|
| Yes there are services like Fargate but they're not cost
| efficient for many cases.
| AviationAtom wrote:
| Most folks have both dev and prod instances.
| kawsper wrote:
| I use their images locally with Qemu, here's an example of an
| address to a qcow2 image:
| https://cdn.amazonlinux.com/os-images/2.0.20210721.2/kvm/amzn
| 2-kvm-2.0.20210721.2-x86_64.xfs.gpt.qcow2
|
| How does one find these links you might ask? Well, I haven't
| found a nice way other than this:
|
| Find the AMIs (newest last)
|
| $ aws ec2 describe-images --region eu-west-1 --owners amazon
| --filters 'Name=name,Values=amzn2-ami-hvm-*-x86_64-gp2'
| 'Name=state,Values=available' --output json | jq -r '.Images
| | sort_by(.CreationDate)' {
| "Architecture": "x86_64", "CreationDate":
| "2021-11-09T04:50:55.000Z", "ImageId":
| "ami-09d4a659cdd8677be", "ImageLocation":
| "amazon/amzn2-ami-hvm-2.0.20211103.0-x86_64-gp2",
| "ImageType": "machine", "Public": true,
| "OwnerId": "137112412989", "PlatformDetails":
| "Linux/UNIX", "UsageOperation": "RunInstances",
| "State": "available", "BlockDeviceMappings": [
| { "DeviceName": "/dev/xvda",
| "Ebs": { "DeleteOnTermination": true,
| "SnapshotId": "snap-0f312650dadc31d95",
| "VolumeSize": 8, "VolumeType": "gp2",
| "Encrypted": false } } ],
| "Description": "Amazon Linux 2 AMI 2.0.20211103.0 x86_64 HVM
| gp2", "EnaSupport": true, "Hypervisor":
| "xen", "ImageOwnerAlias": "amazon",
| "Name": "amzn2-ami-hvm-2.0.20211103.0-x86_64-gp2",
| "RootDeviceName": "/dev/xvda", "RootDeviceType":
| "ebs", "SriovNetSupport": "simple",
| "VirtualizationType": "hvm" }
|
| From the information returned you have to stich the version
| numbers and filenames into this format:
| https://cdn.amazonlinux.com/os-images/2.0.20210721.2/kvm/amzn
| 2-kvm-2.0.20210721.2-x86_64.xfs.gpt.qcow2
|
| And if you did it right, you can now download the file.
| my123 wrote:
| https://cdn.amazonlinux.com/os-images/latest/ exists too.
|
| You'll also find VirtualBox, Hyper-V and VMWare ready
| images in there.
|
| (and also arm64 ones)
| dilyevsky wrote:
| If I remember correctly Go does use libc by default if you
| link with net package (you can set CGO_ENABLED=0 to disable
| it but then you won't get NSS). On openbsd it also switched
| back to using libc
| shaicoleman wrote:
| Currently you have to launch an EC2 instance to test it.
|
| Once it's GA, they'll provide VM images and docker
| containers, so you'll be able to test it offline
| alexdong wrote:
| Are there any quantities data for the performance comparison
| like they did for Aurora vs MySQL? Thanks
| takeda wrote:
| Well, it is generally more likely to be tuned to AWS,
| containing right drivers and tools installed than a default
| distro you would download from the website, but the images
| that are available on AWS would likely also tuned similarly.
| If there are some issues where other image is noticeable
| worse they would look into AmazonLinux and apply the changes
| from it.
|
| I would say that AmazonLinux is likely to have less issues
| with latest instance types (if they change something
| "hardware" wise, for example when AWS started exposing EBS
| using NVMe drivers there were some issues originally).
| cpach wrote:
| I don't understand why this is based on Fedora. Isn't that more
| of a desktop distro...? And this seems more aimed at virtual
| machines running on EC2...? Or am I missing something?
|
| It's also interesting that at the same time Amazon is sponsoring
| Rocky Linux: https://rockylinux.org/sponsors/ (Which is based on
| Red Hat Enterprise Linux.)
| bluedino wrote:
| Fedora has a server edition, and everything in RHEL/CentOS is
| _old_
| afroboy wrote:
| > and everything in RHEL/CentOS is old
|
| This is the whole reason why people use CentOS and Debian as
| server side old stable and most importantly security patch.
| if you need your dev stack as newest version just installed
| it on the old stable OS base so you can worry only on your
| dev stack.
| darkr wrote:
| > CentOS and Debian as server side old stable and most
| importantly security patch
|
| Historically, CentOS has been very slow to release security
| patches, compared to upstream (RHEL). And for anything non-
| critical (but still often high) Debian stable tends to
| receive fixes a lot later than unstable, and sometimes
| never due to need to backport.
| dharmab wrote:
| Speaking as an ex-platform engineer, we needed to be on
| much newer kernel versions to leverage ebpf and other
| modern features
| AviationAtom wrote:
| Fedora is the upstream for RHEL, and was the upstream for
| CentOS. While many folks use Fedora as a desktop OS alternative
| to Ubuntu, Fedora was not designed with desktops in mind.
|
| You are correct saying it is designed for EC2 instances, as it
| is the de facto default image for EC2 instances, despite many
| folks choosing an Ubuntu image instead.
| [deleted]
| shaicoleman wrote:
| "Our release cadence (new major version every 2 years) best
| lines up with a highly predictable release cadence of an
| upstream distribution such as Fedora."
|
| "We believe that having Fedora as upstream allows us to meet
| the needs of the customers that we talked to in terms of
| flexibility and pulling in newer packages."
|
| https://www.reddit.com/r/aws/comments/qzxkh3/comment/hlptw7l...
| bamboozled wrote:
| Stability is important but less and less people seem to want
| to run 4 year old software.
| cpach wrote:
| I think it depends quite a bit on the circumstances.
|
| And as long as the kernel is decently fresh, one can run
| new shiny software using containers instead.
| iou wrote:
| I'm a big SELinux fan and user.
|
| Enabling it won't in itself secure your company's applications,
| as the default policies in Fedora only apply to installed
| services (e.g ssh) that have a policy written for them.
|
| This is probably right on the boundary of the shared-security-
| model, but I think it would be great if they also offered easier
| ways for application developers to leverage the advertised
| feature.
| CameronNemo wrote:
| FWIW, Docker, podman, LXC, and Kubernetes will apply SELinux
| policies to containers automatically if you have that support
| enabled at build time (many distributions do have it enabled,
| esp Fedora family) and SELinux enabled at runtime. Likewise for
| AppArmor.
| imachine1980_ wrote:
| most servers use debian or ubuntu, i think this will be
| greate and maybe even a killer feuture to change a little the
| landscape, but i don't think is as much impact as we wish in
| at least the next 5 years
___________________________________________________________________
(page generated 2021-11-25 23:00 UTC)