When working to support 911 systems we used half rack on wheels. Most very small county PSAP are to small to have a full anchored rack. They could be pushed back when access wasn’t needed, and of course out when needed.
Since emergency calls where being handled by these things, they of course had to be secure.
I'd say there's probably more roles out there to move up into. Companies may be using Microsoft 365, but could be using other providers for their cloud infrastructure. They might also expect their cloud engineers to know multiple platforms. I had experience creating highly available environments on-premise before breaking into Azure.
This is a good point. The number of M365 jobs out there probably outnumbers Azure jobs. And the M365 jobs typically need just one skill, whereas a typical Azure job will require many. And one is a logical step from helpdesk, and one is a total focus change.
When looking at the copyright issues of broadcasting (playing over speakers or display devices) streaming content for public viewing/listening in your office or restaurant, streaming is considered the same as a television or radio broadcast . So the copyright laws regarding playing TV or radio in your office also apply to streaming content.
Example: I have an IPv4 network, and you have an IPv4 network, and we want to talk to each other. But there's no IPv4 network between us. We need to tunnel our networks somehow through whatever is between us so that we can network to each other. That in between network could be anything, NetBEUI, IPX/SPX, IPv6, whatever. As long as we tunnel through it, our IPv4 networks can see each other (but not the network inbetween).
What is the best way to secure the most vulnerable attack vector for a network?
A] Remove unneeded services running on the servers
B] Provide end-user awareness training for office staff
C] Update all antivirus definitions on workstations and servers
D] Use biometrics and SSO for authentication
Hey First Question - Thanks Scott
My first instinct D]Use biometrics and SSO for Authentication
The key words in the question is "most vulnerable attack vector" so IMHO, D] would incorrect.
I thought that too, but then I thought that was too easy and that he probably was meaning something else .
The test SHOULD be too easy. If you really know the material, and are paying attention to the reading (because the questions are designed to not let you skim them), it should feel pretty obvious a lot of the time.
@Pete-S The locking is also what I was referring to. I will most likely set the share up for both and do some testing.
There should be locking from the filesystem so that either Samba or NFS has the file at any given moment. It's the filesystem's job to make sure that two processes can't access any given file at the same time. That the processes are NFS or Samba shouldn't matter. NFS or SMB can have another partial lock on top of that, for sure. But that should be on top of the file level lock.
Which part? I read the part of NFS, but that doesn't seem to apply. That would cause problems, but not corruption problems, right?
Just that comparing windows and *nix you see that there are different file locking mechanisms in play. That is what could cause corruption. Samba has to support Windows mechanisms while it's file system is residing on unix.
For instance from Samba 3.0 documentation (for historical context only):
Record locking semantics under UNIX are very different from record locking under Windows. Versions of Samba before 2.2 have tried to use the native fcntl() UNIX system call to implement proper record locking between different Samba clients. This cannot be fully correct for several reasons. The simplest is that a Windows client is allowed to lock a byte range up to 2^32 or 2^64, depending on the client OS. The UNIX locking only supports byte ranges up to 2^31. So it is not possible to correctly satisfy a lock request above 2^31. There are many more differences, too many to be listed here.
Samba 2.2 and above implement record locking completely independently of the underlying UNIX system. If a byte-range lock that the client requests happens to fall into the range of 0 to 2^31, Samba hands this request down to the UNIX system. No other locks can be seen by UNIX, anyway.
That's very complex. But it sounds like Samba is just... not locking the file and hoping for the best?