Wasabi’s official documentation on using s3fs to mount a storage bucket is lacking an example of using /etc/fstab to persist the bucket mount following a reboot.
To use /etc/fstab to permanently mount a Wasabi bucket using s3fs on Ubuntu, first install s3fs:
sudo apt-get install s3fs Create a filesystem location to mount the bucket:
sudo mkdir /mnt/wasabi_bucket sudo chmod 777 /mnt/wasabi_bucket Create the entry in /etc/fstab:
wasabi_bucket:/ /mnt/wasabi_bucket fuse.s3fs _netdev,allow_other,use_path_request_style,url=https://s3.wasabisys.com,use_cache=/tmp 0 0 Mount the bucket:
I managed several thousand Macintosh desktops in a previous job with the help of Munki, an awesome open-source tool written by Greg Neagle. Alongside Munki, I created munki-enroll, which is now a popular way to manage the automated creation of computer-specific Munki manifests.
I recently worked on a GitHub bug report that was actually not a bug in the munki-enroll code, but instead a problem stemming from a lack of documentation regarding the server-side requirements of munki-enroll.
I have been using AutoKey on my Linux desktop to provide automated text insertion capabilities similar to what I get from AutoHotKey on my Windows systems. I prefer to keep things like my email and ticket signatures stored as hotkeys so I can more granularly choose when to use them.
The version of AutoKey included in the Ubuntu repositories has an issue where blank lines are inserted rather than the expected text.
The root RDS Web Access URL (e.g. https://rds.domain.com) does not redirect to the RDS login screen by default in a Windows Server 2012R2 RDS farm setup. Thankfully, there is a simple change in Microsoft IIS to enable this functionality.
In the IIS Manager on each RDS Web Access server in your farm, select “Default Web Site” from the left pane, and select “HTTP Redirect” from the “Default Web Site Home” pane.
I stood up my first Microsoft Remote Desktop Services several months ago, with a great deal of help from TheWolfBlog’s great guide.
One thing I didn’t have when I started my work was a good illustration of how the final highly-available infrastructure would look. I’ve included an image of a sample setup below, and I hope it benefits someone.
In the image below, the firewalls represent load balancers.
We have lately had a rash of compromised email accounts in our Office 365 Exchange Online infrastructure. It appears a well-crafted phishing email caught at least a small percentage of our 100,000-plus mailboxes.
The outbound SPAM protection in Office 365 and Exchange Online is very robust. Suspected SPAM messages are sent through a high-risk pool of IP addresses, and accounts are limited to 10,000 outbound messages per day before being blocked by the anti-SPAM intelligence.
We had a request to add permissions for a customer throughout a deeply nested structure in our Exchange Online Public Folders.
These commands will not override or change permissions where they are already set.
Connect to Exchange Online PowerShell $Cred = Get-Credential Connect-MSOLService -Credential $Cred $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $Cred -Authentication Basic -AllowRedirection Import-PSSession $Session Add Permissions and Verify Success In PowerShell, run:
Get-PublicFolder -Identity "\Folder Name" -Recurse | Add-PublicFolderClientPermission -User jsmith -AccessRights Owner Verify the change was successful: