+ missing details in each section helping clarity
This commit is contained in:
parent
cb014a4ebf
commit
57c9bc70eb
@ -1,13 +1,15 @@
|
||||
# Intranets
|
||||
|
||||
Topics:
|
||||
|
||||
Focusing on what hardware(things really) is used to setup networks in different places.
|
||||
|
||||
# Bridges
|
||||
## Bridges
|
||||
|
||||
Used to divide a network
|
||||
Used to divide a network thus giving us a form of encapsulation on our network and ergo allow us to delegate some responsibility outwards.
|
||||
|
||||
|
||||
# Ethernet networks
|
||||
## Ethernet networks
|
||||
|
||||
> Hubs
|
||||
|
||||
|
16
412/mail.md
16
412/mail.md
@ -1,22 +1,32 @@
|
||||
# Email Service
|
||||
|
||||
For any email service we have some goals that we would like to keep in mind as we either choose what service to use or build one ourselves:
|
||||
|
||||
|
||||
> Standards
|
||||
|
||||
Try to keep things with standard protocols
|
||||
|
||||
Especially if you try to make your own mail service we don't try to make our own protocols because that makes the service highly incompatible with basically everything else.
|
||||
|
||||
> Automation
|
||||
|
||||
Have some system that can create emails for you instead of manually creating them
|
||||
Have some system that can create emails for you instead of manually creating them.
|
||||
We don't want to go to some database and manually type out all the commands to create a new email everytime; even a set of scripts might be annoying to use unless once every so often.
|
||||
|
||||
An example scenario is a mass hiring season where each new employee requires their own company email. The system we put in place should be able to create an email account for each person without much intervention if any at all(ideally).
|
||||
|
||||
> Redundancy
|
||||
|
||||
Backup mail servers to insure against partial loss
|
||||
Backup mail servers to insure against partial loss.
|
||||
All this really entails is making sure that emails can be verified, to check for errors or generally making sure the emails that users are looking for are available to view.
|
||||
|
||||
> POP/IMAP
|
||||
|
||||
Most servers accept IMAP and not POP anymore
|
||||
Most servers accept IMAP and not POP anymore so our system should be setup to deal with using IMAP as it makes our email service more compatible with other services.
|
||||
|
||||
> Encryption
|
||||
|
||||
For the most part we use SSL on the mail server to retain privacy among the users.
|
||||
Additionally we could setup a system to keep the emails themselves encrypted so even if someone leaked the emails all they would get back is encrypted data.
|
||||
|
||||
|
@ -1,36 +0,0 @@
|
||||
# Midterm Sample Questions
|
||||
|
||||
Difference between NAS and SAN?
|
||||
|
||||
Subnet:
|
||||
|
||||
* What kind of class is the given IP?
|
||||
|
||||
* What is the subnet mask, network address, etc?
|
||||
|
||||
* Subnet addresses?
|
||||
|
||||
`Host & subnet mask(classless)`
|
||||
|
||||
BTW: this is the analog of the network address(classful addressing). When we talk about network addresses we are implying a classful network.
|
||||
|
||||
* Subnet bits
|
||||
|
||||
i.e. 21 => 8+8+5+0 <= `5` is the odd one out so we have _5 subnet bits_
|
||||
|
||||
* VLSM - Variable Length Subnet Mask
|
||||
|
||||
|
||||
Suppose we want to assign addresses to the following networks with x many hosts.
|
||||
A:600; B:1000; C:200
|
||||
|
||||
`150.180.0.0/16`
|
||||
`150.181.0.0/16`
|
||||
|
||||
Start with the largest network B : requires 1000 hosts.
|
||||
|
||||
Hosts part requires 10 bits so we have an IP/22.
|
||||
|
||||
Network address then is (subnet address)150.180.0.0/22 - (broadcast address)150.180.3.255/22
|
||||
|
||||
**NOTE:** I included both the subnet(network) address and the broadcast for sake of brevity.
|
@ -5,6 +5,24 @@ Several types of monitoring:
|
||||
## Building Monitoring System
|
||||
|
||||
If your monitoring a lot of _stuff_ know that you will could have lots of stuff going across the network(in some cases).
|
||||
This is why a good monitoring system shouldn't get in the way of _business traffic_ as the purpose of the network is to service its users.
|
||||
Ultimately however to ensure that things are running smoothly some monitoring must be put in place which means we must use valuable resources to make sure things are behaving correctly.
|
||||
|
||||
How this is done is generally up to implementation but there a few rules of thumb:
|
||||
|
||||
* Don't query everything on the network all at once as you could easily clog the network and drop all kinds of data in the process
|
||||
|
||||
If you must query _all the things_ then try to stagger the query to a few machines at a time, either by scheduling the checks or doing them randomly to avoid them all at once.
|
||||
|
||||
* Limit what kind of data you query for
|
||||
|
||||
The reasoning is the same as before, try to not use too many resources at the same time lest you risk dropping both business and query data
|
||||
|
||||
* Avoid peak times
|
||||
|
||||
All networks have certain hours of the day where usage is at its maximum for the size of that userbase. If you're dealing with a rather large network then definitely avoid doing heavy monitoring tasks during these times.
|
||||
|
||||
|
||||
Know that we have to _get data, store data, and ultimately view data_.
|
||||
|
||||
## Historically
|
||||
|
@ -1,5 +0,0 @@
|
||||
# OpenFiler
|
||||
|
||||
> both on the browser and the regular user account
|
||||
openfiler
|
||||
openfiler
|
Loading…
Reference in New Issue
Block a user