I am writing a bash script to change MAC (Ethernet) address back to default one after changing it.
In order to match the default value and the current value,
the script needs the default value.
However I am not sure where to store the default MAC address.
Currently The address is hard-coded and stored in the script
MAC=**:**:**:**:**
It doesn't seem appropriate to hardcode like this for security purposes,
but retrieving default MAC address seems pretty hard because the MAC address has already changed to another value.
Possible solution is to store it in another file or some other places.
Are there any ideas to solve without hardcoding it?
Protecting a public information like a MAC address is a bit strange but what about cryptography? Let's assume you have GNU gpg installed, and a key pair with identity animal.farm#orwell.gb. Then:
echo "$MAC" | gpg -e -r animal.farm#orwell.gb > ~/.mac
Will encrypt the value of shell variable MAC and store the encrypted value in a file named .mac in your home directory. Decrypt with:
gpg -d ~/.mac 2> /dev/null
If you protected your private key with a passphrase (recommended) you will be asked for it.
Related
There are numerous related questions, but none of the answers solve this specific case:
I am on MacOS, using iTerm2 and ZSH.
Any AWS EC2 instance with the Amazon image (and maybe others) will show me that line when connecting to them with SSH:
setlocale: LC_CTYPE: cannot change locale (UTF-8)
The common answer to this problem seems to be a fix on the server. But this is not what I am looking for, I would like a fix on the client (since we create and destroy EC2 instances quite regularly).
I've tried to add this to my .zshrc file:
export LC_CTYPE=UTF-8
ihinking that if it is already set to that locale, it won't complain. But that didn't work.
In iTerm2, there is an option:
I tried to disable that, but no change as well.
How can this be fixed?
"UTF-8" looks like the name of a charset, not the name of a locale. That may be a valid locale on macOS but probably isn't on the EC2 servers. On a Linux system, you can list available locales with locale -a. Try values like en_US.UTF-8 or perhaps C.UTF-8. If available, the latter is probably preferable.
It is probably better to set it from .zprofile rather than .zshrc and perhaps only conditionally if the existing value is "UTF-8":
[[ $LC_CTYPE = UTF-8 ]] && LC_CTYPE=C.UTF-8
I use the Simba ODBC driver (2.3.2) to connect Stata to BigQuery from my macOS laptop. I recently upgraded to Big Sur (11.2.1) and lost the ability to do this.
I am using iODBC and I am able to test the DSN successfully. I was also able to get everything to work in macOS 10.15.7 just fine (on a different machine).
The problem appears to be that Stata is not seeing the DYLD_LIBRARY_PATH environment variable that I have defined in my .bash_profile profile according to the driver configuration instructions.
In Stata, I get this error:
. odbc list
The ODBC file libiodbc.dylib could not be found on this system.
Setting the unix LD_LIBRARY_PATH environment variable may correct this error.
r(680);
I am able to set this in bash:
$ echo $DYLD_LIBRARY_PATH
:/usr/lib/:/usr/local/
But that does not seem to work since:
$ printenv | grep 'DYLD'
is empty. I suspect something in Big Sur is preventing this environment variable from being set.
Happy to try anything to fix this.
To fix this, you need to disable SIP, which keeps the $DYLD_LIBRARY_PATH environment variable from being defined without issuing a warning.
To disable SIP:
Restart your computer in Recovery mode by holding down Command(⌘)-R once it powers off. Press that until you see the Apple icon and a progress bar.
From the Utilities menu, select Terminal.
At the prompt, type the following command and then press return: csrutil disable
Terminal should display a message that SIP was disabled.
From the Apple menu, select Restart.
Now you need to define an environment variable that points to the folder with libiodbc.dylib. To figure out where that folder is, type this in Terminal:
find / -name libiodbc.dylib 2>&1 | grep -v "find: "
Using your favorite text editor (like pico, emacs, or vi), you need to edit your .zshenv file. Open this file (or create it if it does not exist) with
pico ~/.zshenv
Using the first folder from above, define an environment variable by typing this in the file:
export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:<FOLDER-PATH-HERE>
Save and exit the text editor.
To apply the changes to the current shell, type source .zshenv.
This should make Stata and BQ play nice again.
zsh is the default shell starting with Catalina, so if you use another shell, you should modify things accordingly. I use bash myself, but I hope my translation for zsh works.
You may need to start Stata from the command line for this to fully work.
Here's the output of the command after the fix above:
I got this to work on Apple Silicon/ Monterey. At some point Apple rolled out SIP (https://support.apple.com/en-us/HT204899) and the env variable LD_LIBRARY_PATH is no longer accessible, so STATA is unable to find the .dylib file.
Instead of disabling SIP, which is strongly discouraged by Apple, load STATA from the command line and set LD_LIBRARY_PATH in the same command.
Something like this (your paths and STATA version may vary)
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/homebrew/lib/ && \
/Applications/Stata/StataIC.app/Contents/MacOS/StataIC &
I am trying to check the default homepage in Safari on Mac OS X 10.10 Yosemite.
On my vanilla system the homepage isn't actually set, so first I forcibly set the HomePage using command:
defaults write com.apple.Safari.plist HomePage www.google.co.uk
Now I can read the HomePage setting using this command:
defaults read com.apple.Safari.plist HomePage
www.google.co.uk
is the output.
I need to do this for the console user using a Bash Script that is delivered and executed by Microsoft SCCM. The Microsoft SCCM Client runs under the machine's system account so running the defaults read command above does not report the logged-in user's setting. To work around this I am using commands that first determine the logged-in user's userID and then another to read the HomePage value using a full path to the logged-in user's (if applicable) instance of the Safari plist file.
If I execute the top four lines manually, the expected homepage is stored in variable myuserhompage and is displayed as expected.
myuser=$(stat -f%Su /dev/console)
myuserhompage="$(defaults read /users/$myuser/library/preferences/com.apple.Safari HomePage)"
if [[ ${myuserhompage} == "www.google.co.uk" ]] ;
then
echo "homepage_set"
exit 0
else
echo "homepage_not_set"
exit 1
fi
However when I run the same lines of code from within a Bash script, I see The domain/default pair of does not exist error.
By re-typing the text directly into the OS X VM instead of relying on copy/paste from a Windows host I now appear to get consistency between the terminal command line and scripted commands. This has resolved my issue. It also highlighted an issue with the result evaluation which I have updated accordingly. Thanks.
I'd like to mount a Samba drive in OS X using bash. This line does the trick:
mount -t smbfs //$SAMBAUSER#$ADRESS/$NAMEOFSHARE $MACOSXPATH
only one problem. I want it done without user input - which means no password can be manually put in. And I'm not going to ask my users to download fink just so they can install expect (as seen here).
I tried applying the accepted solution to a similar StackOverflow problem shown here by doing this:
echo "mypassword" | mount -t smbfs //$SAMBAUSER#$ADRESS/$NAMEOFSHARE $MACOSXPATH --stdin
but no luck - that doesn't work and Mac OS X tells me I used mount command improperly:
usage: mount [-dfruvw] [-o options] [-t ufs | external_type] special node
mount [-adfruvw] [-t ufs | external_type]
mount [-dfruvw] special | node
Any suggestions? This would be easy with an expect script - but that would ruin the user experience to have that prerequisite in my mind.
If mount(8) can't just call the mount syscall on the filesystem, it looks for a program to help it. On FreeBSD and Mac OS X, those helper programs follow the naming convention mount_XXX, where XXX is the -t argument's value.
That means you want to check the mount_smbfs(8) man page, which tells us about -N:
-N Do not ask for a password. At run time, mount_smbfs reads the ~/Library/Preferences/nsmb.conf
file for additional configuration parameters and a password. If no password is found,
mount_smbfs prompts for it.
Unfortunately the man page trail ends with one for nsmb.conf that doesn't mention anything about storing passwords. On FreeBSD 8.0, at least, the solution is to put a password key with a plain text(!) password value under a [SERVER:USER] heading. That would be type C according to the linked nsmb.conf man page.
So it seems that you'll want to dump a pre-configured nsmb.conf into your user's ~/Library/Preferences/ directory and then call your mount command with -N. As far as I know you can't provide a hashed value, which is not especially awesome. I'll try to get access to a MacBook in a few hours to test this.
NB: This is not how to do it with the GNU toolchain. If you're on Linux, you're probably going to be using something like mount.cifs(8). The correct solution in that case is the credentials=filename option (used after -o, of course), where filename is a file of credentials in key=value form, separated by newlines. See http://linux.die.net/man/8/mount.cifs
The answer in this apple support discussion thread worked for me:
osascript -e 'mount volume "smb://user:password#server/share"'
I'll give you 2 options. First, include the password on the command line:
mount -t smbfs //$SAMBAUSER:$PASSWORD#$ADRESS/$NAMEOFSHARE $MACOSXPATH
This is not a great option because the command line (including password) is visible to anyone who happens to be logged in at the moment. Not great, but it is a possibility.
Second, use expect. The Mac OS X Hints article you linked dates from 2002, when OS X v10.2 would've been current. While 10.2 apparently didn't include expect as a standard component, 10.6 does, and I'm pretty sure it's been included for several versions now.
#!/usr/bin/expect -f
spawn mount -t smbfs //fred#12.34.56.78/myfiles /tmp/mountpoint
expect "Password:"
send "wibble\r"
wait
You not only can use a hashed value, you're expected to, at least in older releases. The crypt option for smbutil is not DOD-level security but as with most security, you're trying to keep the honest people honest: the bent ones will find a way. It seems to be broken in Mountain Lion but the nsmb.conf file in ~/Library/Preferences should be secure at the OS level. The /etc/nsmb.conf would override it if it exists. I'm sure there's a reason why plain text files are obsolete but didn't we go this with NetInfo? How long did it take for Apple to allow the old standbys (/etc/hosts, /etc/passwd) to be used?
When I use VIM in the terminal on my local machine (Mac OS X Snow Leopard), the delete key is really backspace (i.e., destructive backspace).
When I SSH into a particular server, for some reason it's regular delete (i.e., delete the character under the cursor).
How can I change it to be consistent? I've tried a dozen solutions, but nothing seems to work.
Checking the "Delete sends Ctrl-H" box in Terminal Preferences->Advanced doesn't work -- this is non-destructive backspace.
I've tried about a hundred different key mappings in VIM, to no avail.
Interestingly, the key works as expected when I'm typing commands in VIM (e.g., : <something>) -- it's only screwed up when I'm editing the actual text. Any ideas?
This worked for me:
:set backspace=indent,eol,start
I'm not sure exactly what it does but it is listed as a possible solution here and here. I found this line in a vimrc file distributed with Ubuntu where the behavior of the mac "delete" key (otherwise known as the "backspace" key) works as expected without any other configuration.
The behavior I was experiencing was a bell sound (no characters deleted) when pressing the mac "delete" key (otherwise known as the "backspace" key) in insert mode. I am using a compiled version of vim 7.3 on "amazon linux" over ssh from a mac. Pressing <ctrl-v><delete> when in insert mode resulted in ^?.
Couple of ideas to try:
In your .vimrc file on the remote server, add this line:
set term=linux
In your .bash_profile file (or whatever corresponds to your shell of choice) on the remote server:
stty erase ^H
Note: to make this work correctly, you must type ctrl-v, then ctrl-h to type the ^H character.
Also, make sure "Delete sends Ctrl-H" is checked in your Terminal prefs.
Try this: http://www.alecjacobson.com/weblog/?p=295
I fixed the problem by changing my Terminal.app settings. Under Terminal > Preferences choose Advanced. Check “Delete sends Ctrl-H”. Now, vi and vim should understand the delete key more intuitively.
Note: Mapping the “delete” key in my vimrc file seemed like probably the correct way to do this, but that’s a lot of trouble. Is there any reason not to do it this way?
Try adding
set <Del>=<C-v><Del>
to the vimrc on the target machine. Here you must type <C-v><Del> while being logged on the target machine. If this does not work, check verbose imap <Del>: this should tell you whether some plugin has remapped <Del> in insert mode.