From https://littlesvr.ca/grumble/2023/01...uction-to-aws/

I thought there might be some interest in this forum.

===============

Having looked at the AWS Academy introduction courses multiple times: I decided that they are completely useless as a learning tool. I don't like that they read like a commercial, and they make the bizarre assumption that Linux experience is not a prerequisite.

I decided to build my own Introduction to AWS course and I did. Here it is. The weekly schedule has links to all the materials and videos which you might call “Lectures”.

All you need is there, except access to an AWS Academy Learner Lab. You do need an AWS account. So if you have one and are willing to pay for the resources you’ll use: you don’t need anything else.

After about the middle of the course you’ll need access to a system I built to function as a free registrar (Bindistrar). Just contact me and I’ll make you an account.

Obviously I do not have the ability to rubber-stamp any diplomas or certificates for you, but if you just want to learn: I believe this course is a great resource.

I do assume some basic Linux knowledge. If you’re not completely lost when presented with a bash shell: your background might be good enough.

I am currently working on another course where I teach basics of Linux server administration. You can follow the progress here. That course is intended to be taken before this one, but it won’t be finished until 2-3 months from now.

Feel free to send me any questions any time.

Looks like a quite interesting start. Four comments , jumping ahead to week 12?

1. Commodity technologies enable and encourage innovation through healthy competition, which in turn increase choice and open entirely new markets. A commodity market is where sources of products and services are interchangeable and is good for buyers (your students and the rest of us). So, even though the one course, OPS345, is about AWS and, presumably, its more or less proprietary interface, I'd mention as many of the standard, commodity capabilities as possible. That would also reinforce learning by building on OPS245 and open, modular systems help avoid vendor lock-in and that applies to both data and skills.

2. The other class, OPS245, which you are considering for a prerequisite can probably be boiled down to working with SSH, simple shell scripts, tmux tips and tricks, and configuration of sudo/doas. Maybe touch on least privilege and privilege separation in regards to services. Depending on how much you plan to cover, orchestration tools like Puppet, Chef, Ansible, etc might be of use towards the end.

3. The billing for AWS (and other hosted services) can be deadly so ways to keep a lid on unneeded instances seems important, as well as quickly detecting any changes which would affect costs before they run up a killer tab.

4. nftables is a bit easier to use and certainly to configure, IMHO. Furthermore it is where the development is happening, so iptables skills will not age well and are beginning to be more or less deprecated these days.

And, out of curiosity, two questions: How many hours per week are students in the classroom and how many additional hours per week are they expected to work on their own for 1 credit? Why roundcube instead of mailpile?

Thanks for the feedback!

Indeed, and that's the reason I've been teaching on local machines for many years. But the reality is that the jobs are moving to the cloud, and begrudgingly I built a cloud course

I picked AWS because I figured Amazon must be better than Microsoft. I wish the skills were completely transferrable, but unfortunately AWS has its own name for the most basic components. That sucks. I looked into setting up a private cloud some years ago, but that experiment failed - the software just wasn't ready and the hardware requirements were very serious.

It's going to be all Debian (with Mint just for GUI comfort). Do you have any suggestions about how to teach configuration management tools like Ansible? I looked into it a long time ago and couldn't figure out what's worth teaching there. It might be my lack of experience.

Yep. It's bloody aweful. I'm convinced that AWS made their billing intentionally obscure, so you can never figure out exactly what your money is being spent on. But so far none of my students went over 100$ going through the entire course, which I find reasonable.

I struggled a lot with this decision. The situation is supposed to be that iptables is being replaced by nftables, but the people working on nftables say themselves it is not the firewall of the future. And iptables is used all over the place. And nftables isn't any less complex than iptables to a beginner. And I don't know what the future solution is supposed to be, or whether it will be adopted.

I almost didn't put iptables into the course either, but I really wanted the students to understand some basics of what a typical firewall does, and I feel the GUI in AWS isn't enough on its own to impart the importance of the concepts.

Since I work for a typical diploma mill: getting the credit requires about 4 hours of work a week, most of my students don't show up to class. But to really learn this stuff: I'd say at least 10 hours a week, and obviously it helps if you have someone to discuss the issues you're working through.

I've never heard of Mailpile. Their website says it's being rewritten. Is there something particularly good about it?

It's certainly an interesting project.

For "cloud" AWS is one of the safe choices. Despite the tremendous noise from Redmond, m$ is not really a major player in "cloud" as far as market share goes and appears to be shuffling their budget around to fake the appearance of growth in that sector. There are also OCI, GCP, OVH, and Linode plus a few others.

I won't go as far as to say that "cloud" is a passing fad but the byzantine billing rules and very high prices appear to have created a minor resurgence, or at least interest, in self-hosting even if only as a means to reduce costs. There is also, oddly enough, a high cost to outsourcing sysadmin skills and that can be expensive for a business once a tipping point has been crossed and the experienced people follow each other out the door.

Getting across the very idea of modularity or a la carte systems can be a challenge for those who have grown up with only monolithic systems.

If you are using a GUI, then I would say that one useful tip is to encourage them to set the title on each of the terminal emulator's windows as soon as each new window is opened. That makes it much easier to keep track of multiple open windows. (Setting the icon for each window would be outside the scope of OPS345 but maybe draw on material from ULI101 and be something some of the more interested student could figure out on their own, outside of class. Or there are many other ways to get the more motivated ones to explore the system on their own.)

I don't have any direct advice specific to Ansible. I only looked at Ansible early on and, at the time, found it faster to just pound out quick shell scripts combined with SSH. The initial set up is obviously important and sometimes kind of difficult with orchestration tools, also several common example scenarios like updating HTTP configuration files and SSH configuration files or system updates. Since there are a lot of people who swear by ready-made orchestration tools, I would recommend asking in a separate thread about the tools specifically.

Knowing what a packet filter does is useful knowledge. Though once they are demystified, they often turn out to be unnecessary. Even rate limiting is not very useful any more since so many attacks come from distributed pools of compromised Windows machines and rarely from single machines any more.

For my part, ipchains was easy, iptables never became even remotely comfortable, and nftables has been complex but far less so than iptables. PF, of course, is best of all but not available for Linux. The main two selling points which I see for nftables in the classroom is that it can be fully controlled by a single configuration file and that a single command can both clear the rule set and load new rules. That is unlike iptables which is more like scripting and difficult to deal with such as trying to track the ever-changing line numbers.

I had not seen that it is undergoing a refactoring / rewrite. Given that it's being rewritten, it'd be more appropriate to wait and see what they actually come up with before further exploration. There has not been a status report on the rewrite since the announcement. One thing is that, if completed, it'll be in Python3 after the rewrite.