Q.) What are the core components of a HTTP response?
Bonus Q.) What is a cached response?
Q.) Imagine you find a critical process on a server that has stopped logging. What are the most common causes, and how would you fix them?
Q.) If You have a /24 network and need subnets for 50 and 100 hosts. Design the subnets.
I'll be posting a series of Linux-related questions covering various skill levels. Feel free to share your insights and expertise. Your contributions will benefit learners at all stages, from those in current roles to those preparing for Linux interviews.
I will attempt the logging related question -
When a process stops logging, my first step is always to confirm that the process is still running. If it is, I immediately investigate log rotation. It's a common issue where the log file rotates, but the process continues writing to the old file, which a quick restart will resolve.
I also check for full partitions using the “df -h” and “df -i” commands. Insufficient disk space or unavailable inodes is a frequent cause of logging failures.
Another possibility is a “permissions” or “SELinux denial”. I'll check the file permissions with ls -lZ and review the audit logs for any clues.
Finally, if the process uses a logging daemon like journald or syslog, I'll check “journalctl” and ensure the daemon itself is running without issues.
In my experience, these issues often come down to log rotation, disk space, or a problem with the logging daemon.
Q.) If You have a /24 network and need subnets for 50 and 100 hosts. Design the subnets.
Let me take a whack at this low-hanging fruit.
What I'll do for starters is to subnet the /24 network into 2 subnets, using a /25 mask. This will give me 2 subnets, with 126 host addresses. So, I'll use one of these subnets to accomodate the 100 hosts requirement. The network address for this network will be X.X.X.0/25.
To accomodate the network that has only 50 hosts, I'm going to subnet that remaining subnet - this will give me 2 additional subnets, each able to support 62 hosts. By subnetting that remaining subnet, this is essentially doing what many know as subnetting a subnet. I'm doing this because, I disapprove of waste. Knowing that I require a network (i.e. subnet) that only needs to accommodate 50 hosts, a good design approach is to carve up this remaining subnet (that can accommodate 126 hosts), so that it can take care of the 50 hosts requirement, and still have another subnet, that will accommodate another 62 hosts, for any future requirements.
The end result is that I will have 3 subnets:
- 1 with a /25 mask, to accomodate the 100 hosts
- 2 with a /26 mask, where one of these is accomodating the 50 hosts
With a whiteboard, I would paint a picture of this that would make Picasso proud
Q.) What are the core components of a HTTP response?
The core componets of an HTTP response are:
- Status Line
- Headers
- Body
Here is an example of a Status Line:
HTTP/1.1 200 OK
The Status Line containts three important components:
1) HTTP Version
2) HTTP Response Code
3) a Reason-Phrase
The HTTP version number shows the HTTP specification to which the server has tried to make the response message comply. In the example above, 1.1 is the HTTP version.
The HTTP Response Code is a 3-digit number, that shows the conclusion of the Request. In the example above, the response code 200 denotes that the content requested was OK. A status code that is not a welcomed one, but is sometimes encountered, is 404, which represents the requested resource was not found
The Reason-Phrase, is also known as Status Text, as it summarizes the Status Code in a human-readable form.
The Respose Header contains the informatin about the content that is being returned in response, together with data about the Server that sent the data. This information helps the Client/Browswer in deciding in what way the response data would be used. Phrased in another way, headers can be said as metadata, that is sent together with a response, to provide more info about the response.
The Server can send as many headers as needed. The headers are sent as a key-value pair, separated by a colon. Although the Server can send as many headers as required, the most popular response headers are:
- Content-Length
- Content-Type
- Date
- Server
- Set-Cookie
- .. and others
Date: Wed, 16 July 2022 10:10:10 GMT
Server: Apache/2.4.54 (Unix)
Content-type: image/jpg
The above 3 lines represent an example of a Response Header. In the example, the response header shows the date and time when the response was sent, the server that sent the response, and the type of content (a jpg image file) that was sent.
The final core component of an HTTP response is the Body. When a response is successful, the Body of the Response Message is used to serve the Client/User with the resource asked for in the request. The Body carries the data, and can be in one of many formats such as, json, html, image, and others - this format is specified in the headers.
In the case of some errors, the Body might provide the reason for the erros, or the actions need to complete the request successfully. There are times that the Body may have a link to guide the user to some other page.
I will attempt the logging related question -
When a process stops logging, my first step is always to confirm that the process is still running. If it is, I immediately investigate log rotation. It's a common issue where the log file rotates, but the process continues writing to the old file, which a quick restart will resolve.
I also check for full partitions using the “df -h” and “df -i” commands. Insufficient disk space or unavailable inodes is a frequent cause of logging failures.
Another possibility is a “permissions” or “SELinux denial”. I'll check the file permissions with ls -lZ and review the audit logs for any clues.
Finally, if the process uses a logging daemon like journald or syslog, I'll check “journalctl” and ensure the daemon itself is running without issues.
In my experience, these issues often come down to log rotation, disk space, or a problem with the logging daemon.
Q.) If You have a /24 network and need subnets for 50 and 100 hosts. Design the subnets.
Let me take a whack at this low-hanging fruit.
What I'll do for starters is to subnet the /24 network into 2 subnets, using a /25 mask. This will give me 2 subnets, with 126 host addresses. So, I'll use one of these subnets to accomodate the 100 hosts requirement. The network address for this network will be X.X.X.0/25.
To accomodate the network that has only 50 hosts, I'm going to subnet that remaining subnet - this will give me 2 additional subnets, each able to support 62 hosts. By subnetting that remaining subnet, this is essentially doing what many know as subnetting a subnet. I'm doing this because, I disapprove of waste. Knowing that I require a network (i.e. subnet) that only needs to accommodate 50 hosts, a good design approach is to carve up this remaining subnet (that can accommodate 126 hosts), so that it can take care of the 50 hosts requirement, and still have another subnet, that will accommodate another 62 hosts, for any future requirements.
The end result is that I will have 3 subnets:
- 1 with a /25 mask, to accomodate the 100 hosts
- 2 with a /26 mask, where one of these is accomodating the 50 hosts
With a whiteboard, I would paint a picture of this that would make Picasso proud
@Trevor Thanks for your explanation!
Q.) Imagine you find a critical process on a server that has stopped logging. What are the most common causes, and how would you fix them?
Okay, I'm going to initially have a look at some of the things involving the process itself. Is there an issue with the system resouces? Did the system all of a sudden run low on memory? If so, that Linux Out-Of-Memory frowns on this condition, and shows no favoritism when it comes to who's going to get the ax (i.e. terminated).
Did you know that a process has a limit on the number of open file descriptors? Yeah, it does! If it's reached that limit, how is it going to be able to open its log file, to write to it!
So, these are just a couple of possibilities as to why this critical process has stopped logging.
In the case of a potential memory issue, I'm simply going to explore what caused the hiccup in memory exhaustion. If it's not too taxing, I'll add some additional memory to see if this can resolve the issue quickly.
In the case of file descriptor limit issue, if the critical process is managed by systemd, I'm going to create what's known as an override file. It certainly would be a preferred approach - having to expand the file descriptor limit based on a single process, and not take a system-wide approach.
In summary, if the process ain't running, it ain't logging. Let's see if memory exhaustion is responsible for that. If the process is running, and the number of file descriptors that are able to be opened has been exceeded, there will no writing, to what cannot be opened.
Bonus Q.) What is a cached response?
I do love this question!!!!
Some additional info on this:
- The Linux kernel automatically manages the page cache, utilizing available RAM to store frequently accessed disk data
- By reducing the need for disk I/O, cached responses significantly increase the speed of file operations, and overall system responsiveness
- The size of the page cache dynamically adjusts, based on system usage and available memory. If apps require more memory, the kernel will reclain memory form the cache by dropping older, less frequently used data. Ah, the kernel!!!
- Cached memory is technically "used" by the kernel. However, it is considered "available" because it can be readily freed and allocated to apps when needed. You can see this reflected in tools like free or top, where cached memory is shown as part of "buff/cache".
This is such a beautiful topic!!!
@Trevor regarding the Logging failure Q - I feel that the answer is incomplete as you have only limited your approach to FD limits and OOM. As a sysadmin you should also think on the lines of :
Disk full (/var/log or wherever logs are written). Permission issues (process user can’t write to log file). Log rotation misconfiguration (old file handle not released). Application-level bugs (logging function crashed). SELinux policies blocking writes. Syslog/rsyslog/journald misconfigurations.
you mentioned “if the process ain’t running, it ain’t logging” - but also many a times process is in running state but logging fails because of the above reasons.
Also, I would prefer investigation why the memory leak happened at the first place and you are right about FD limit increase and we should also mention in our answer about monitoring the open files with lsof -p <pid>.
Thank you for being a valuable member of this community ! You rock!
@Trevor Regarding the cached response Q - You have explained Linux page cache very well. But I am the culrpit here - I could not frame the Q better however I did put it as bonus under the http Q.
My original Q was asked in the context of web servers, APIs, CDNs, or DNS.
Chetan, I'll never see you as a culprit as long as you're providing those immensely challenging questions!!!
Chetan, shame on me for making this admission publicly, but when I responded, I went after the lowest hanging fruit. My other "excuse" is that I only provided a couple of reasons for the logging issue because I wanted to save something for others who may have wanted to respond to the query.
The community will surely benefit much more from the additional info that you provided!!!
Thank you making me a valuable member of the community!!!
Red Hat
Learning Community
A collaborative learning environment, enabling open source skill development.