With MacOS and finder you can easily substitute characters of files using the rename functionality. Just select 2 or more files, right click, and inform the character you want to substitute, like _ with space.
To remove the last N characters from a file that looks like Text-2018221112.mp4 to Text is more complicated. The rename dialog does not understand regex. What you can use is the shell and rename
Install rename
brew install rename
Go to the directory with the files and run
rename -n 's/.{11}.mp4/\.mp4/' *
Rename uses the well known sed syntax s/char/replace/.
-n runs the replace in simulation mode. It will print the result, without renaming the files yet. Perfect for testing.
{11} number of characters to replace
\.mp4 is to insert mp4 again, as .{}11.mp4 will replace also the file suffix
In case the output matches your goal, run rename without -n and the files will be renamed.
Issuing an AJAX request is more complex than you might think.
Issue
When you issue an AJAX request to a server in another domain (CORS), you may get the following error message:
Response for preflight does not have HTTP ok status.
Problem
The server is configured to allow CORS. The Apache configuration includes
Header set Access-Control-Allow-Origin "*"
The response header of the service contains the correct header value. With this set you can access the service via CORS.
Solution
Now, why does it not work?
You have to be aware that this works for simple CORS requests. For more complex requests that set custom headers, etc, the service may not work. This is due to the preflight mechanism of the browser that checks if the service accepts the request. Before issuing an AJAX request (e.g. GET or POST), an OPTIONS is triggered to check what the service is accepting. You can see this in the network tab of Chrome.
The request includes two headers:
Access-Control-Request-Headers
Access-Control-Request-Method
Before issuing the actual GET request, the browser is checking if the service is correctly configured for CORS. This is done by checking if the service accepts the methods and headers going to be used by the actual request. Therefore, it is not enough to allow the service to be accessed from a different origin, but also the additional requisites must be fulfilled.
Solution
To configure Apache to set the headers, add the missing headers. Include in your HTTP service configuration the header set directive.
Header always set Access-Control-Allow-Origin "*"
Header always set Access-Control-Allow-Methods "POST, GET, OPTIONS, DELETE, PUT"
Header always set Access-Control-Allow-Headers "append,delete,entries,foreach,get,has,keys,set,values,Authorization"
Still not working!
After setting the values, you may still not able to call the service, as the browser still reports an error. The response code is not 2xx. Returning a 200 HTTP code can be enforced in Apache config using a rewrite rule.
RewriteEngine On
RewriteCond %{REQUEST_METHOD} OPTIONS
RewriteRule ^(.*)$ $1 [R=200,L]
With this configuration, the service will now work with CORS. The first OPTIONS request will pass:
The example used in this blog is a CIFS share from a Samba server running on a Raspberry Pi mounted on demand by a client running Debian.
Goal
The goal is to have a share on a client that is dynamically mounted. The share should only be mounted when an app needs to access.
In my case I do have a server with a data storage share connected. The storage is made available to clients in the network. To not have the share being mounted by the clients all the time, the share should be mounted only when real demand exists. For instance, an app needs to read data from the share. If the share is not needed by the client, it should not be mounted.
Process
To understand the scenario better, take a look at the picture below. The process can be separated into 4 steps.
Step 1: the client is configured, but the share is inactive.
Step 2: An app is accessing the share. This can be an app as simple as ls /mnt/share
Step 3: The client is connecting to the server and mounting the share to the local mount point /mnt/share. The data is now available to the app.
Step 4: The app is not using the data from the share any longer. After a timeout, the client disconnects the share.
The example is using for the server a Raspberry Pi with Raspbian and for the client a Debian based system (Proxmox). As share type, CIFS is used. On the client, Samba is running and configured to give access to a named user to the data storage.
Installation
Server
Install Samba and configure access for a named user. This is not part of this blog.
Client
Autofs is the package and tool taking of mounting shares automatically. Install it using apt-get.
apt-get update
apt-get install autofs
Configuration of autofs
Autofs needs to be configured. To make it easier, the packages comes with templates. I am going to use the autofs master template as my starting point. Take a look at the master template as it contains an explanation of what is needed.
cd /etc/auto.master
more /etc/auto.master
To add an auto mount share a new line must be added to the file. The format is: mount-point file options.
Before adding the line, you first must understand how the template and autofs works and what you want to achieve. First parameter is for the local mount point. The directory informed here is the parent. The actual shares mounted are created as sub-folders in that directory. For instance, if you choose /mnt/server and the remote share is data, the final mount point will be /mnt/server/data. I am going to mount the remote share to /mnt/server.
The seconds parameter is for the configuration file for that mount point. The third parameter specifies how autofs is treating the mount point. To unmount the share after 1 minute of inactivity, use option –timeout=60. The ghost option will create the subfolder even in case the server is not reachable.
Edit master template
Add a new configuration line for mounting the server share
The actual mount configuration for the share is specified in the file /etc/auto.server. Create file /etc/auto.server and edit it.
touch /etc/auto.server
vim /etc/auto.server
Insert mount options.
[username] – name of user used to connect to Samba share
[password] – password of the user
[remote_server] – IP / server name of the Samba server
/data – name of the share configured at Samba. In case you have a share configured named Music, or Fotos, or Work, substitute data with the correct share name.
data -fstype=cifs,username=[username],password=[password] ://[remote_server]/data
Save file
Change permission
chmod 0644 auto.server
Start autofs as service
Stop autofs and start it in debug mode to see if the configuration works.
If it worked, exit and start the service.
systemctl start autofs.service
Test
To test, go through the 4 steps described in the picture at the top of this blog.
Step 1
Client is ready. Check the mounted volumes. You will see that no CIFS volume is available.
Using mount, you can see that the mount point is available.
/etc/auto.server on /mnt/server type autofs (rw,relatime,…
In the parent mount point for the CIFS share, autofs created the folder data.
Step 2 & 3
Run an app that is accessing the share
ls /mnt/share/data
Accessing now the content of /mnt/server/data will automatically mount the CIFS share.
df -h
Mount
//192.168.0.164/data on /mnt/server/data type cifs (rw,relatime
Step 4
Assure that no app is using the share and wait until the specified timeout occurs. Check with mount and df to see that the share is umounted.
I use cookies to ensure that I can give you the best experience on my personal website. If you continue to use this site I will assume that you are happy with it.Ok
