Speaker 1: Welcome to the Deep Dive. We're the show where we
Speaker 1: tackle a big pile of source material.
Speaker 2: And we boil it all down for you, pulling out
Speaker 2: the key insights you need to.
Speaker 1: Know, basically saving you the reading time but giving you
Speaker 1: the knowledge exactly. And today we are diving into something
Speaker 1: pretty hands on excerpts from the Sendos six Linux Server cookbook.
Speaker 1: Think of it like a set of technical recipes.
Speaker 2: Right for getting a Linux server, specifically Cento six running
Speaker 2: and managed properly.
Speaker 1: So our mission, our goal for this deep dive is
Speaker 1: to unpack the core tasks, the fundamental knowledge from these excerpts.
Speaker 2: We want to pull out those key recipes that solve
Speaker 2: the common problems you'd face administering a CentOS six box.
Speaker 2: See what makes this guide useful and you spot the
Speaker 2: really interesting bits.
Speaker 1: It's like getting the chef's notes for building and running
Speaker 1: a server. Now. It is technical, no doubt about it,
Speaker 1: but we're going to translate the important stuff, highlight the
Speaker 1: core steps. Whether you're just curious about servers, or maybe
Speaker 1: you need to get up to speed quickly for work.
Speaker 2: Or you just want to understand those basic build of blocks.
Speaker 1: Right, let's dive in.
Speaker 2: Okay, so where better to start than the beginning installation.
Speaker 1: The source kicks off right there, and even before the
Speaker 1: actual install, it highlights something simple but easy to forget.
Speaker 1: Checking your installation media.
Speaker 2: Yeah, verifying the integrity using the MT five some tool.
Speaker 2: It mentions, it's like you wouldn't start cooking with ingredients
Speaker 2: you weren't sure we're good.
Speaker 1: Yeah, good point. Okay, so you've verified the download during
Speaker 1: the install itself. What are the key checkpoints?
Speaker 2: Well, the source stress is setting a proper host name.
Speaker 2: Don't leave it as localhost dot local domain.
Speaker 1: Oh yeah, that default is pretty useless on a network.
Speaker 2: Totally give it a real name early. Also, confirming your
Speaker 2: hard disk partitioning storage setup is fundamental.
Speaker 1: Get that wrong and you're in for a headache later.
Speaker 2: Definitely. And it touches on Grub the bootloader. Now, messing
Speaker 2: deeply with Grub can be tricky even for experienced people.
Speaker 2: Yeah right, but the book points out you can password
Speaker 2: protect Grub during installation. That's a nice little security win.
Speaker 1: Right at the start, the source seems to really push
Speaker 1: for a minimal install Why go minimal when there are
Speaker 1: those package groups you can just select?
Speaker 2: Ah, that's a core philosophy here It boils down to
Speaker 2: efficiency and really security security. How a minimal install gives
Speaker 2: you only the absolute bear essentials. The idea is it's
Speaker 2: much safer to add only what you need later, configuring
Speaker 2: it carefully as you go, instead.
Speaker 1: Of starting with a bunch of stuff you might not need,
Speaker 1: which could have vulnerabilities.
Speaker 2: Exactly, you reduce the initial attack surface. Fewer running services
Speaker 2: means fewer potential ways in for an attacker, makes sense.
Speaker 1: Less is more security wise? Okay, Minimal installed done? What
Speaker 1: are the first basic config steps.
Speaker 2: Post install essentials? The book hits things like changing the
Speaker 2: time zone use the subtle it command, then make it
Speaker 2: stick in your profile files like dot bash profile.
Speaker 1: You can use location names or the post six format
Speaker 1: like GMT five YEP.
Speaker 2: Both options are covered and related to time. Synchronizing the
Speaker 2: system clock with NTP, the Network Time Protocol.
Speaker 1: Crucial for logs security, lots of things rely on accurate
Speaker 1: time totally.
Speaker 2: You'd use the NTPD service, configure it in EXITCNTP dot
Speaker 2: com and you can check sync status with NTPPP.
Speaker 1: But NTP isn't there by default on a minimal install.
Speaker 2: Good point. The source notes that you'll need to yum
Speaker 2: install NTP.
Speaker 1: First, all right, networking the absolute backbone, setting a static
Speaker 1: IP address versus just letting DHP assign one.
Speaker 2: This is a key recipe for any server. The book
Speaker 2: shows editing the interface can fig like if cfg eth zero. Oh.
Speaker 2: The crucial bit is telling network manager to keep its
Speaker 2: hands off by setting NM controlled no.
Speaker 1: Ah. Okay, so you explicitly take control, right.
Speaker 2: Then you set boot proto none and manually put in
Speaker 2: your IPADR netmask and your gateway and epsconfit network predictable
Speaker 2: fixed address essential for a server.
Speaker 1: Got it? And then there's this thing called channel bonding
Speaker 1: Ethernet bonding.
Speaker 2: Yeah, that's about combining multiple network interfaces like two Ethernet
Speaker 2: ports into one logical interface.
Speaker 1: Why would you do that?
Speaker 2: Two main reasons redundancy If one cable or port fails,
Speaker 2: the other keeps working, or increased throughput, potentially doubling your bandwidth.
Speaker 1: Okay, And the source gives the setup steps.
Speaker 2: It gives the basics for creating the bond interface config
Speaker 2: ifcfg bond zero and loading the bonding kernel module. It
Speaker 2: sets remodprobe dot de bonding dot com. It mentions master
Speaker 2: and slave interfaces and that you might need to experiment
Speaker 2: with different bonding modes depending on your network switch and
Speaker 2: what you need.
Speaker 1: Sounds like something you need to test carefully. It also
Speaker 1: covers setting the fully qualified domain name FQDN yeah.
Speaker 2: Your server's full name on the network host name plus
Speaker 2: domain name. The book shows you edicisconfin network and echosts,
Speaker 2: and it throws in a reminder about valid characters and
Speaker 2: length for host names. Easy details to miss.
Speaker 1: Cylenex comes up next. Security Enhanced Linux big topic.
Speaker 2: It is very powerful mandatory access control system. The source
Speaker 2: introduces its purpose and shows how you can change its
Speaker 2: mode enforcing, permissive or disabled by editing.
Speaker 1: It sesses stanicfig but it also mentions reasons why you
Speaker 1: might disable it seems counterintuitive for security.
Speaker 2: Well, it acknowledges reality. Sometimes certain applications or say web
Speaker 2: hosting control panels, just don't work properly with the Linux
Speaker 2: enforcing rules. So while disabling it is a definite security hit,
Speaker 2: the book lists as an option if compatibility is a
Speaker 2: major roadblock, it's a tradeoff.
Speaker 1: Another potential tradeoff mentioned is disabling IPv six.
Speaker 2: Why IPv six is the future designed to fix IPv
Speaker 2: four running out of addresses, But as the source notes,
Speaker 2: maybe your network doesn't use it yet, or some services
Speaker 2: aren't fully compatible.
Speaker 1: So disabling it could simplify.
Speaker 2: Things potentially, yeah, maybe slightly. Less admin overhead removes one
Speaker 2: theoretical attack vector if it's unused. The book shows the
Speaker 2: configure edits IPv six il mit no IPv six io
Speaker 2: connecto no, but it clearly warns don't do this if
Speaker 2: you might need IP. Turning it back on isn't always straightforward.
Speaker 1: Right, another careful decision. Okay, that covers the initial install
Speaker 1: on basic setup. What about the day to day running
Speaker 1: of the server, users, packages, logs, that sort of thing.
Speaker 2: User management is first, and the big rule the source emphasizes,
Speaker 2: don't operate as the route user all the time, standard.
Speaker 1: Security practice, right, Create a regular admin.
Speaker 2: User exactly, use user AD and password. Then the book
Speaker 2: clarifies the difference between Sue and Pseudo. Very important distinction.
Speaker 1: Yes, Sue lets you become another user, including root if
Speaker 1: you know their password, full power.
Speaker 2: Right, whereas Pseudo leads a permitted user run specific commands
Speaker 2: with root privileges using their own password.
Speaker 1: And crucially, Pseudo logs everything.
Speaker 2: Audit trail precisely. Pseudo is much more granular and safer
Speaker 2: the source shows how you can restrict SUE access just
Speaker 2: to members of the wheel group by editing at setsepam
Speaker 2: dot DSU, and it points out that Pseudo isn't configured
Speaker 2: by default on Cento as six, so you actually have
Speaker 2: to set it up.
Speaker 1: Which you do using the pseudo to safely edit itt
Speaker 1: setus suitors an. These specific pseudo security tips highlighted.
Speaker 2: Yeah, it mentioned setting a timestamp come out so your
Speaker 2: pseudo authentication expires after a while, and setting required you
Speaker 2: which forces pseudo commands to be run from a proper terminal.
Speaker 1: Session ah, so not easily run from automated scripts or
Speaker 1: weird context exactly.
Speaker 2: Good protection. And it shows how to send all pseudologs
Speaker 2: to a dedicated file like varlog pseudo dot log for
Speaker 2: easier auditing.
Speaker 1: Makes sense. Then package management YUM the definitive package manager
Speaker 1: for CentOS six, the book.
Speaker 2: Says, and the beauty of Yum, which the source highlights
Speaker 2: is dependency resolution. You say YUM install something, and it
Speaker 2: figures out everything else that something needs and installs it
Speaker 2: all automatically.
Speaker 1: Takes a lot of the headache out of managing software,
Speaker 1: so updates are just YUM update.
Speaker 2: YEP and The source notes you usually don't need a
Speaker 2: full reboot after updates, though maybe restart specific services.
Speaker 1: Practical tip and cleaning the package cash with YUM clean
Speaker 1: all right.
Speaker 2: And automating updates using yumcron you can figure it, schedule
Speaker 2: at this confidgium cron, set it and forget it.
Speaker 1: Mostly automating maintenance is key. What about removing packages with
Speaker 1: yum remove any warnings there?
Speaker 2: Big warning? Always always read the list of packages Yum
Speaker 2: says it's going to remove, along with the one you
Speaker 2: asked for. Check those dependencies.
Speaker 1: You could acidentally rip out something critical.
Speaker 2: Easily, so pay attention to that summary before you hit
Speaker 2: you Good.
Speaker 1: Advice Finding packages uses yem search or yum list. What
Speaker 1: about yem.
Speaker 2: Provide ah Yum provides a super handy If you need
Speaker 2: a specific file or command, say easer bint pass would,
Speaker 2: but don't know which package it belongs to, you can
Speaker 2: do Yum provides us a spin pess wood and yum
Speaker 2: will tell you which package to install.
Speaker 1: Nice trick. The source also talks about adding extra repositories
Speaker 1: like epel or remy.
Speaker 2: Why do that because the defaults intos repositories are stable
Speaker 2: but sometimes conservative These third party repos like EPEL extra
Speaker 2: packages for enterprise Linux offer a much wider selection of software,
Speaker 2: often newer versions.
Speaker 1: But there's a catch. Conflicts.
Speaker 2: Yeah, potential conflicts. Two different repos might offer the same package,
Speaker 2: maybe different versions or built differently. This can cause problems.
Speaker 1: And the solution is that YUM plug in priorities package.
Speaker 2: That's the recommended way. You install that plug in. Then
Speaker 2: you edit the dot repo files in SCM dot repos
Speaker 2: dot D. For each repo you add a priority n line.
Speaker 2: Lower number means higher priority, so.
Speaker 1: You tell YUM check CentOS official first priority one, then
Speaker 1: EPEL Priority ten, then maybe remy priority twenty exactly.
Speaker 2: It helps YUM make sensible choices when there's overlap. You
Speaker 2: can also enable or disable repos entirely in those files
Speaker 2: with enabled one or zero.
Speaker 1: Okay. Moving to logs dot log Rotate essential The sources
Speaker 1: absolutely essential.
Speaker 2: Log files grow and grow Without rotation, they'd fill your
Speaker 2: disk and become useless. Log Rotate automates managing them.
Speaker 1: How does it work?
Speaker 2: It usually runs daily via cron. It checks its main
Speaker 2: config at a clog rotate dot com half and more importantly,
Speaker 2: the specific canfig files for different services in a cloak
Speaker 2: rotate dot D based on the rules in those.
Speaker 1: Files like how many old logs to keep?
Speaker 2: Yeah, things like rotate in keep in old logs, compress,
Speaker 2: zip up old logs size x, rotator if it hits
Speaker 2: size x. Note of empty, don't rotate a empty create
Speaker 2: make a new empty log file after moving the old one.
Speaker 2: And poster tate lets you run a command like telling
Speaker 2: a service to reopen its log file.
Speaker 1: Being able to rotate based on size not just time
Speaker 1: sounds useful for noisy service.
Speaker 2: Very practical, yes.
Speaker 1: Lastpit on core operations, dot memory checking usage and clear
Speaker 1: in the cash.
Speaker 2: Right free, MRM and TOP are your go two tools.
Speaker 2: The book explains the free output, pointing out that the
Speaker 2: line showing plus buffers cash gives you a better idea
Speaker 2: of memory actually available.
Speaker 1: To applications because Linux uses free RAM for disc cacheing.
Speaker 2: Exactly, which is good for performance. But sometimes you might
Speaker 2: want to see that cash cleared. The source gives the
Speaker 2: command sink first then echo three proxis VM drop caches?
Speaker 1: Is that risky?
Speaker 2: The book says it's generally safe, but it's not something
Speaker 2: to do Routinely. Clearing the cash means the system might
Speaker 2: have to reread stuff from disc immediately after, which can
Speaker 2: spike IO and CPU temporarily. Use it if you have
Speaker 2: a specific reason.
Speaker 1: And like updates. You can automate this cash clearing with
Speaker 1: crime yep.
Speaker 2: Put those commands in a script, schedule it with corontab e.
Speaker 2: Another maintenance recipe.
Speaker 1: Okay, solid foundation. Now security hardening before we even think
Speaker 1: about web servers or databases absolutely critical.
Speaker 2: The source spends good time here starting with SSH secure shell.
Speaker 2: The main way in remotely.
Speaker 1: Needs locking down. First step recommended.
Speaker 2: Deny root log in directly, set permit root log in
Speaker 2: no and ed centris config force logins as a normal user.
Speaker 2: Then use Pseudo much safer makes sense.
Speaker 1: Changing the default port away from twenty two.
Speaker 2: Also recommended change the port xxx line. It won't stop
Speaker 2: a determined attacker, but it cuts down hugely on automated bots.
Speaker 2: Hammering port twenty.
Speaker 1: Two easy win. What else for us is H.
Speaker 2: Limit who can log in, use allow users or allow groups,
Speaker 2: and should config to specify exactly which users are groups
Speaker 2: are allowed SSH access, restrict the entry points right and
Speaker 2: maybe add a warning banner using banner et ceter mud
Speaker 2: and show the last log in time with print last
Speaker 2: log yes, remind users document access and always service first
Speaker 2: restart after changes.
Speaker 1: Okay beyond SSH the firewall ip.
Speaker 2: Tables installed by default on CentOS six powerful chain base filtering.
Speaker 2: The book guides through setting.
Speaker 1: Up rules, starting with allowing in central traffic yeah like.
Speaker 2: Loop back traffic for the server to talk to itself,
Speaker 2: I aload, maybe traffic from specific trusted ips manas for source,
Speaker 2: oilers D for destination, and crucially allowing established connections m
Speaker 2: state's late establish related so ongoing traffic works.
Speaker 1: And then opening specific ports for your services TCB twenty
Speaker 1: two for SSH, eight ERROOHO four four.
Speaker 2: Three for web exactly you poke holes only for what
Speaker 2: you need, TCP port fifty three, UDP fifty three for DNS,
Speaker 2: TCP twenty five for SMTP mail, UDP one twenty three
Speaker 2: for MTP and so.
Speaker 1: On, and the most important principle.
Speaker 2: Set the default policy to drop iptable's dash P input,
Speaker 2: drop fiptible dash P fourward drop, deny everything unless explicitly allowed,
Speaker 2: the secure default and save the rules.
Speaker 1: The service syptables save makes them permanent across reboots. Service
Speaker 1: Emptable's restart applies changes now. The book also shows simple
Speaker 1: rules to specifically allow or block certain IP addresses.
Speaker 2: What about automating defense against attacks? Fail to ban into
Speaker 2: my hosts great tools?
Speaker 1: Fail to ban is really versatile. It watches log files,
Speaker 1: not just SSH but others too, for patterns like repeated
Speaker 1: failed logins and then what when it sees too many
Speaker 1: failures from one IP, automatically adds an IP tables rule
Speaker 1: to block that IP for a while.
Speaker 2: Wow active defense.
Speaker 1: Yeah, you can figure it in jail dot com set
Speaker 1: things like ban time, how long the block lasts, and
Speaker 1: max freetree how many failures trigger the ban. Can also
Speaker 1: send email alerts. SSH is usually covered by default, and
Speaker 1: deny hosts is.
Speaker 2: It similar similar, but specifically focused on SSH dictionary attacks.
Speaker 2: It also watches logs, blocks ips. The source says it's simpler,
Speaker 2: smaller footprint. Can figure it in deny hosts dot cfg.
Speaker 2: Mainly just setting your email, but it warns be careful
Speaker 2: not to block your own IP.
Speaker 1: Huh yeah, that would be. Lastly, on security, anti virus
Speaker 1: clam av right.
Speaker 2: Linux servers aren't immune to hosting or passing on malware,
Speaker 2: even if they don't run typical Windows viruses, so scanning
Speaker 2: is wise. Clam scan is the.
Speaker 1: Command and the source gives a script to automate scanning
Speaker 1: certain directories.
Speaker 2: Yep, clamaf dotsh example, log the results and you'd schedule
Speaker 2: that script with Karan automating security checks.
Speaker 1: Okay, foundations laid, system hardened. Now let's look at setting
Speaker 1: up the actual server roles databases. First, my squall and Postgres.
Speaker 2: Scool common requirements for my squel. The source covers the
Speaker 2: install YUMP install my skull server, making sure it starts
Speaker 2: on boot and can fig my squold on and starting
Speaker 2: it serves my squoiled start. Then a critical next step my.
Speaker 1: School secure installation.
Speaker 2: Absolutely, don't skip the script, the book explains. It walks
Speaker 2: you through setting the root password, removing anonymous users, blocking
Speaker 2: remote root log in, removing test databases, essential hardening, and.
Speaker 1: Then creating databases and users from the mychocal command line.
Speaker 2: Yes, it's show the sequel. Create database dB name, create
Speaker 2: user at host identified by password, and grant privileges on
Speaker 2: dB name to user at host.
Speaker 1: Granting specific permissions, not just giving everyone full.
Speaker 2: Access exactly, and importantly, run flush privileges to apply those
Speaker 2: grants without restarting my school.
Speaker 1: What about postgres School? Similar process?
Speaker 2: Pretty similar? Start install the packages POSTGRESCOO server Postgres school contrib,
Speaker 2: initialize the database cluster service Postgres school in and at BB,
Speaker 2: enable and start the service. Then use preachers and created
Speaker 2: bataka commands and interact with PCL.
Speaker 1: How does remote access work for Postgres School's different from
Speaker 1: my squel's user grants? Right?
Speaker 2: Yes, it uses a host based authentication system. You can
Speaker 2: figure it in the PGHPA dot com file. The book
Speaker 2: shows how to edit this file to allow connections from
Speaker 2: certain IP addresses or networks postlines and specify the authentication
Speaker 2: method often MD five for password encryption.
Speaker 1: Got it okay? Switching to email post Fix and DOFCOT.
Speaker 2: The standard combo Postfix is the MTA, the Mail Transport Agent.
Speaker 2: It handles the sending and receiving between servers.
Speaker 1: Configure it in main dot CF to handle mail for
Speaker 1: your domain.
Speaker 2: Right, set interior faces all to listen on all network interfaces.
Speaker 2: Define your domains in my destination and.
Speaker 1: The book has that cool talent trick for testing SMTP.
Speaker 2: Yeah, connect to port twenty five using telnet and manually
Speaker 2: type SMTT commands like all mail from dot RCPT two
Speaker 2: dot data. Great way to check if postfix is alive
Speaker 2: and responding correctly.
Speaker 1: Okay, so Postfix moves the mail Dovecot lets users access
Speaker 1: it exactly.
Speaker 2: Dovecot provides the IMP and pop three services that email
Speaker 2: clients connect to install it. You installed dovecot enable it.
Speaker 2: Configuration is in dovecot dot CF and its confaft dot.
Speaker 1: D directory key Dovecot settings mentioned.
Speaker 2: Enabling protocols, protocols, map pop three, setting the mail location,
Speaker 2: mail location, mail dear, and interestingly for basic local user setups,
Speaker 2: allowing plaintext authentication disable plaintextos as you.
Speaker 1: Know, plan text passwords.
Speaker 2: Isn't that bad over the open Internet? Yes, absolutely, but
Speaker 2: the context here seems to imply for local clients or
Speaker 2: scenarios where maybe TLS is enforced. Elsewhere, It's another one
Speaker 2: of those configuration choices with security implications depending on.
Speaker 1: Your setup, and Postfix needs to use dovecot to check
Speaker 1: passwords when users try to send mail SMTPAUA.
Speaker 2: Correct you set up SASL authentication in postfixes main dot CF,
Speaker 2: telling it to use dovecot via settings like SMTPD, sysyl type, SMTP,
Speaker 2: saslpath SMTPD and solventable.
Speaker 1: The book also touches on basic spam filtering in Postfix yes.
Speaker 2: Using header checks and body checks to define rules that
Speaker 2: match patterns and email headers or content to block or
Speaker 2: flag spam.
Speaker 1: Very practical. What about handling multiple domains on one server
Speaker 1: virtual domains?
Speaker 2: This is a really common need. The source shows how
Speaker 2: to set this up efficiently. You list your extra domains
Speaker 2: in virtualace domains in main dot CF. Then you create
Speaker 2: a mapping file, usually et cetera, a postfix virtual.
Speaker 1: And in that file you list email addresses and the
Speaker 1: system user they map too, like sales at otherdomain dot
Speaker 1: com on real user one exactly.
Speaker 2: Then you run postmap etc postfix virtual to create a
Speaker 2: database file. Postfix can read quickly, and you tell postfix
Speaker 2: where that map is using virtual as maps equals hash
Speaker 2: dot ECC postfix virtual. The book notes you can handle
Speaker 2: tons of domains this way.
Speaker 1: Can you even set up catch all addresses.
Speaker 2: Yep at domain dot com catchallser simple aliases for system
Speaker 2: users go in achiliuses, then run nualliuses.
Speaker 1: And tools for sending mail from the command line mail.
Speaker 2: X or MUTT standard tools. MUD is mentioned for handling
Speaker 2: attachments and forwarding roots mail using a rude dot forward file.
Speaker 2: All essential mail admin tasks.
Speaker 1: Okay onto the web server a patchegtpd, the.
Speaker 2: Classic install HTTPD, maybe mod Perl, definitely the PHP package
Speaker 2: for Php support. Configure the basics in httpd dot com.
Speaker 1: How do you make sure a patchee serves Php files.
Speaker 2: Add index dot php to the directory index directive in
Speaker 2: hgtpd dot com. That tells a patchy to look for
Speaker 2: index dot php as a default page in a directory.
Speaker 2: And the book suggests creating a quick phpinfo dot php
Speaker 2: file in your web root forw optimilo just to test
Speaker 2: PHP is working.
Speaker 1: Securities paramount for web SSL https absolutely.
Speaker 2: The source shows how to create a self signed certificate
Speaker 2: using OpenSSL. You install modsel first.
Speaker 1: This is it for public sites, right, browsers won't trust it.
Speaker 2: Correct, you'd get a cert from a proper certificate authority
Speaker 2: for a public site. But this recipe shows the process
Speaker 2: of generating the private key and the certificate file opensell rec.
Speaker 1: Asking for country Org and the crucial common name your
Speaker 1: server's domain or IP exactly.
Speaker 2: Then you can figure apaches ssl dot com file, telling
Speaker 2: it where the certificate SSL certificate file and private key
Speaker 2: SSL certificate keyfile are, and a vital step crab mod
Speaker 2: four hundred on those keysert files. So only root can
Speaker 2: read them protect that private key.
Speaker 1: What about user directories that username url style.
Speaker 2: Yeah, modu thirdter comment on shirt hosting, you uncommon this
Speaker 2: line and httpd dot com to include conf dot do
Speaker 2: ser dot com, then potentially edit that file. The book
Speaker 2: even includes a troubleshooting tip about suxx sometimes causing issues
Speaker 2: and how to find and maybe temporarily disable it if needed.
Speaker 2: Very practical detail.
Speaker 1: And the big one for hosting multiple sites. Name based
Speaker 1: virtual hosts fundamental.
Speaker 2: Let's want a patche server on one IP address handle
Speaker 2: many different websites. You tell apatche and httpd dot com
Speaker 2: to include config files from say, httpdv hosts dot.
Speaker 1: E, and then create a dot com file in there
Speaker 1: for each website.
Speaker 2: Right inside each file's virtual host block, you set things
Speaker 2: like server admin, email, server name, the main domain server
Speaker 2: alias like www dot domain dot com, document root where
Speaker 2: the site's files live, and separate airlog and custom log
Speaker 2: files for that specific site. It's the blueprint for multi
Speaker 2: site hosting.
Speaker 1: Just need to put an index dot html or index
Speaker 1: php in that document root exactly. Last server role FTP
Speaker 1: with vs FTP.
Speaker 2: Very secure FTP dayman. The source praises it as fast
Speaker 2: light and secure install ym install, VSFTPD enable start.
Speaker 1: Basic config and VSFTPD dot com key settings.
Speaker 2: Turn off anonymous access a non emositable no, allow local
Speaker 2: system users, local YenS, allow uploads, writenable yes, and maybe
Speaker 2: enable ask moode for text file transfers.
Speaker 1: Security is always a worry with FTP.
Speaker 2: Crew essential set cruit local looser Yes. This locks users
Speaker 2: into their home directory so they can't wander around the
Speaker 2: server file system.
Speaker 1: Can you make exceptions.
Speaker 2: Yes, use crute listenable yess and define a fove cruitless
Speaker 2: file atcvs ftpdcruit list listing users who shouldn't be cruited.
Speaker 1: Managing logins uses ftpsers denied users and user list denied
Speaker 1: or allowed depending on user lists deny and you can
Speaker 1: customize the log in banner message standard stuff.
Speaker 2: Secure connections via ssltls are also covered.
Speaker 1: Similar to a patchy enable it point to this. Certain
Speaker 1: key files.
Speaker 2: YEP sleainable, YZS, VARSUS cert file, RSITE private key file
Speaker 2: encrypts the login and data transfer much safer than plain FTP.
Speaker 1: What about virtual users users not tied to system accounts?
Speaker 2: Very useful feature. The book shows the recipe set up
Speaker 2: a pamcnfig file for VSFTPD create a sex file with
Speaker 2: usernames and passwords logins dot txd hash it into a
Speaker 2: database dpload dot logins dot dB then tell VSFTPD in
Speaker 2: its config to use this database. Guestable wise map guests
Speaker 2: to a system. User guests user name of Peter point
Speaker 2: to the database user BPAs flever way.
Speaker 1: To manage lots of FTP only accounts. Other VSFTP tips.
Speaker 2: Hiding user group IDs, hides ye ss, allowing anonymous uploads
Speaker 2: securely by changing ownership chowne uploads, yuss chry to use
Speaker 2: her name, disabling recursive listings, also recursible to save resources
Speaker 2: and setting idle timeouts, Lots of practical config options.
Speaker 1: Okay. That covers the main technical recipes. The source also
Speaker 1: briefly mentions the book's reviewers.
Speaker 2: Yeah, just to give context, people from e commerce, government, IT, universities,
Speaker 2: tech QA folks like Ugo, Belevance, bin Wa, Benedetti, Frank
Speaker 2: Lemon real world experience behind these recipes, and.
Speaker 1: They apparently share an appreciation for open source fitting for.
Speaker 2: Sentas definitely and it mentions packed publishings focus on specific tech,
Speaker 2: their online library and an open source royalty scheme. Tying
Speaker 2: it back to that open source ethos, so quite.
Speaker 1: A detailed journey through send US six server admin.
Speaker 2: Via these excerpts, we really covered the life cycle, didn't
Speaker 2: we From install and basic config.
Speaker 1: Through daily ops, users, packages, logs, memory.
Speaker 2: Critical security, hardening, sship tables, fail.
Speaker 1: To ban, and then setting up the workhorses databases, mail,
Speaker 1: web FTP.
Speaker 2: This deep dive really pulled out those practical step by
Speaker 2: step guides the recipes you'd need for common Center six tasks.
Speaker 2: It's a good shortcut to understanding these components, and hopefully for.
Speaker 1: You listening, understanding these commanding and fig files gives you
Speaker 1: a sense of power, the ability to build secure many
Speaker 1: of these environments, or just understand them better.
Speaker 2: It demystifies a lot of it.
Speaker 1: Okay, here's a final thought to leave you with. We
Speaker 1: saw repeatedly with things like root log in, Selenix choices,
Speaker 1: plaintext off for local mail, disabling IPv six many recipes
Speaker 1: involved explicit trade offs convenience versus security.
Speaker 2: Usually HM that came up a lot.
Speaker 1: What does this constant need to make? These balancing acts
Speaker 1: tell us about the fundamental challenge of server administration keeping
Speaker 1: things working smoothly while also keeping them safe. It seems
Speaker 1: like a perpetual tightrope walk.
Speaker 2: Definitely something to chew on as you deal with servers
Speaker 2: in the real world.
Speaker 1: Thanks for joining us with a deep dive. Hope this
Speaker 1: was useful for you