Archive

Archive for the ‘Unix’ Category

Customizing Terminal behavior for documentation needs

July 14, 2022 Leave a comment

As part of writing documentation today, I was given a script to follow when making some videos as part of the documentation process. The script included the following requirement:

  • Prepare the Terminal to not show the hostname or the logged-in user

By default, Terminal in macOS Monterey will show both. How to get rid of this?

Screen Shot 2022 07 14 at 3 27 15 PM

Fortunately for me, @scriptingosx had already documented how to do this as part of this post. You can use the PS1 environmental variable to set how your prompt appears in Terminal. After some experimentation, I set the following environmental variable:

PS1="\$ "

To have this prompt appear whenever I opened a new Terminal session, I added the following line to a newly-created .zshrc file in my home folder:

export PS1="\$ "

The .zshrc file is a configuration file for the zsh shell, so adding that and then opening a new Terminal window gave me a prompt which looks like this.

Screen Shot 2022 07 14 at 3 07 10 PM

As part of making the videos, I also noticed that when I copied and pasted a command into the Terminal that the pasted text was highlighted automatically. I’d seen this before and ignored it, but I thought it might be an unnecessary distraction for those watching this video later, so I went looking for how to disable it.

Screen Shot 2022 07 14 at 3 14 30 PM

After some research, I found that this was zsh’s “bracketed paste” feature, which was introduced as part of zsh 5.1. This feature can be turned off using the following command:

unset zle_bracketed_paste

Screen Shot 2022 07 14 at 3 15 20 PM

Adding entries for both the prompt and turning off bracketed paste to my .zshrc file gave me the Terminal behavior I wanted:

export PS1="\$ "
unset zle_bracketed_paste

Screen Shot 2022 07 14 at 3 19 14 PM

I also performed additional customization of my Terminal experience, but those modifications were managed using a configuration profile. For more details on that, please see this previous post:

https://derflounder.wordpress.com/2019/12/19/deploying-terminal-profile-settings-using-macos-configuration-profiles/

Zsh history command doesn’t show all history entries by default

January 30, 2022 1 comment

Starting with macOS Catalina, Apple’s default shell for the Terminal changed from bash to zsh. As part of that change, the behavior of the history command changed.

Bash:

Running the history command lists all history entries.

Zsh:

Running the history command lists only the 15 most recent history entries.

To see more history entries, you can pass a numerical value to the history command. However, the bash and zsh shells handle this differently also.

Bash:

history (number_goes_here): Shows the most recent entries as defined by the number.

For example, the command shown below will show the fifteen most recent entries:

history 15

Zsh:

history (number_goes_here): Shows all entries which follow number_goes_here.

For example, the following command will show all history entries after history entry #1 (which will include all history entries):

history 1

history -(number_goes_here): Shows the most recent entries as defined by the number.

For example, the command shown below will show the fifteen most recent entries:

history -15

For those interested in why this behavior is different, I recommend reading the zshbuiltins manpage’s section on the fc command. This can be accessed by running the following command:

man zshbuiltins

The reason is that in the zsh shell, the history command’s mechanism is using the following built-in function:

fc

Screen Shot 2022 01 29 at 9 58 36 PM

For my own needs, I wanted to recreate bash‘s default behavior for the history command in the zsh shell. The way I chose to do this was to add the following line to the .zshrc file in my home folder.


alias history='history 1'

view raw

.zshrc

hosted with ❤ by GitHub

Screen Shot 2022 01 29 at 8 50 22 PM

The .zshrc file is the configuration file for the zsh shell and is used to customize the zsh shell’s behavior. Adding this line to the .zshrc file will run the following command whenever the history command is invoked:

history 1

The downside to this approach is that it interferes with the original functionality of the history command. An alternative approach would be to add the following line to the .zshrc file:


alias fullhistory='history 1'

view raw

.zshrc

hosted with ❤ by GitHub

Screen Shot 2022 01 29 at 9 11 05 PM

Now all history entries will be displayed when the following command is entered:

fullhistory

Categories: macOS, Unix

Setting up an ad-hoc TCP listener for connection testing using Python’s web service

September 14, 2021 1 comment

I recently needed to set up a connection test so that an outside vendor could verify that firewall rules had been set up correctly on both ends and that a connection which originated at a specific IP address on the vendor’s end was able to resolve a DNS address on our end and make a connection.

I remembered that Python has a simple way to set up a web server, so I decided to use this to create a script which creates a connection listener by setting up a web server on the desired port. For more details, please see below the jump.

Read more…

Categories: Linux, macOS, Scripting, Unix

Fixing Homebrew’s rsyslog on macOS Catalina

February 26, 2020 1 comment

As part of some recent testing, I needed to install rsyslog and the instructions I had referenced using Homebrew to do it. I used the following procedure to do it:

1. Set up a new VM running macOS 10.15.3 in VMware Fusion.

2. Inside the VM, open Terminal and install Homebrew by running the following command:

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

3. Once Homebrew was installed, install rsyslog by running the following command:

brew install rsyslog

4. Copy a pre-configured rsyslog.conf file to /usr/local/etc/rsyslog.conf.

5. Set the following permissions on /usr/local/etc/rsyslog.conf:

File permissions

Owner: root - read, write
Group: wheel - read
Everyone: read

6. Start rsyslog by running the following command with root privileges:

brew services start rsyslog

When I checked on rsyslog though, it wasn’t running or accepting logs from remote Macs like it should be. What had happened?


Update – 3-5-2020: The problem described by this post has now been fixed:


 

For more details, please see below the jump.

Read more…

Categories: Mac administration, macOS, Unix

Enabling Touch ID authorization for sudo on macOS High Sierra

November 17, 2017 10 comments

My colleague @mikeymikey brought this tweet by Cabel Sasser to my attention yesterday:

I have a Touch ID-enabled MacBook Pro and use sudo frequently, so I’ve implemented this on my own laptop. For more details, see below the jump.

Read more…

Categories: Mac administration, macOS, Unix

Disabling login to the root account by changing the root account’s user shell

March 19, 2017 1 comment

While discussing various issues with a colleague, he mentioned that he was seeing the root account enabled on several machines where it should not have been. In general, the root account on macOS is not needed for system administration and should be disabled so he asked if there was a way to use the dsenableroot command to disable the root account without also needing to provide a password.

Unfortunately, disabling the root account by using the dsenableroot -d command does require providing a password as part of the command.

Screen Shot 2017 03 19 at 4 55 17 PM

However, it is possible to disable logins to the root account without using the dsenableroot -d command. For more details, see below the jump.

Read more…

Fixing server connection issues by changing network interface order

October 25, 2016 1 comment

I had one of my customers report a problem today after applying software updates to his Mac. His Mac had been able to automount certain network shares via NFS before the updates, but was unable to access those shares following the updates.

I connected remotely to the Mac and verified that I was unable to manually mount the NFS mounts.


computername:tmp username$ cat /etc/automounts/misc
mars -fstype=nfs,rw,bg,hard,intr,tcp,nolock server.name.here:/misc/datastore
pluto -fstype=nfs,rw,bg,hard,intr,tcp,nolock server.name.here:/misc/roulette
sol -fstype=nfs,rw,bg,hard,intr,tcp,nolock server.name.here:/misc/sol
computername:tmp username$ mkdir misc
computername:tmp username$ mkdir -p misc/datastore
computername:tmp username$ mkdir -p misc/pluto
computername:tmp username$ mkdir -p misc/sol
computername:tmp username$ sudo mount -t nfs server.name.here:/misc/datastore /tmp/misc/datastore
Password:
mount_nfs: can't mount /misc/datastore from server.name.here onto /private/tmp/misc/datastore: Operation timed out
computername:tmp username$ sudo mount -t nfs server.name.here:/misc/datastore /tmp/misc/datastore
mount_nfs: can't mount /misc/datastore from server.name.here onto /private/tmp/misc/datastore: Operation timed out
computername:tmp username$

view raw

gistfile1.txt

hosted with ❤ by GitHub

When I tried to run the showmount command to get a list of the available NFS mounts on the server, I also received a timeout message:


computername:~ username$ showmount -e server.name.here
showmount: Cannot retrieve info from host: server.name.here: RPC failed:: RPC: Timed out

view raw

gistfile1.txt

hosted with ❤ by GitHub

I was about to send this on to the team that handled our NFS shares, when I remembered I hadn’t verified that I could access the server. Sure enough, I couldn’t:


computername:~ username$ ping server.name.here
PING server.name.here (192.168.0.23): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
^C
— server.name.here ping statistics —
6 packets transmitted, 0 packets received, 100.0% packet loss
computername:~ username$

view raw

gistfile1.txt

hosted with ❤ by GitHub

I could ping Yahoo however, so I could contact the internet.


computername:~ username$ ping wwww.yahoo.com
PING oob-media-router-rc1.prod.media.wg1.b.yahoo.com (72.30.203.4): 56 data bytes
64 bytes from 72.30.203.4: icmp_seq=0 ttl=54 time=16.922 ms
64 bytes from 72.30.203.4: icmp_seq=1 ttl=54 time=18.082 ms
^C
— oob-media-router-rc1.prod.media.wg1.b.yahoo.com ping statistics —
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 16.922/17.502/18.082/0.580 ms
computername:~ username$

view raw

gistfile1.txt

hosted with ❤ by GitHub

So I couldn’t access an internal network resource, but I could access the internet. What made this puzzling was that I was connecting remotely to the Mac via the IP address associated with this person’s Ethernet address. This IP address should not have had issues accessing internal network resources. What had happened? For more, see below the jump.

Read more…

tty_tickets option now on by default for macOS Sierra’s sudo tool

September 21, 2016 3 comments

While working on some documentation, I noticed a behavioral change in macOS Sierra’s sudo tool that was different from how sudo behaves on OS X El Capitan.

El Capitan

if you run sudo in one Terminal session and authenticate with your password, then open another Terminal session and run sudo, you won’t be prompted for your password in either Terminal session until the normal sudo authentication timeout. To see what this behavior looks like, please see the video below:

Sierra

If you run sudo in one Terminal session and authenticate with your password, then open another Terminal session and run sudo, you’ll get asked for your password in the second Terminal session too. Meanwhile, in the first Terminal session, you won’t get prompted again until the normal sudo authentication timeout. To see what this behavior looks like, please see the video below:

The difference is that Apple has compiled sudo on Sierra to include the tty_tickets option, which ensures that users need to authenticate on a per-Terminal session basis.

Screen Shot 2016 09 21 at 3 06 19 PM

 

This option had not been included in sudo on OS X El Capitan and earlier, which had been viewed as a privilege escalation vulnerability.

If you want sudo to return to using the pre-Sierra behavior on macOS Sierra, edit /etc/sudoers to add the following option:


Defaults !tty_tickets

view raw

gistfile1.txt

hosted with ❤ by GitHub

 

Screen Shot 2016 09 21 at 2 25 38 PM 

Exporting Unix man pages to plain text files

July 13, 2016 6 comments

While working with different versions of Mac OS X and macOS, it’s often been useful to me to be able to export the contents of a particular command line utility’s Unix man page to a plain text file. Man pages are the built-in documentation method available in Unix-based systems, so Apple documents how to use the various command line tools used by the operating system using this documentation method.

Exporting to a plain text file allows me to compare macOS Sierra’s man page for a particular command line utilty to a exported copy of the same utility’s man page from OS X El Capitan and see where changes to the man page have been made. This comparison is made by using diff, or other file comparison tools like Kaleidoscope, which helps me quickly spot where Apple has made changes to their documentation.

To export man pages to a plain text file, I use the col command line utility to read the contents of the man page in using stdin, then export out to a plain text file using stdout As an example, here’s how to use col to export the diskutil man page to a new plain text file named diskutil.txt:

man diskutil | col -bx > /path/to/diskutil.txt

In this case, col‘s -b and -x functions are used to make sure that the formatting for the diskutil man page remains intact when exported to the plain text file.

Editing /etc/sudoers to manage sudo rights for users and groups

July 11, 2016 11 comments

In some environments, it may be desirable to give users admin rights while restricting those users from being able to run commands with root privileges while using the command line.

A way to achieve this “admin user in the GUI, standard user on the command line” method is to edit the /etc/sudoers file. This is the configuration file referenced by the sudo command line tool, which allows a user with the correct sudo rights to execute a command with root privileges, or using another user account’s privileges.

By default, all user accounts with admin rights on both OS X and macOS have full rights to use the sudo tool. By removing those accounts’ rights for sudo from the /etc/sudoers file, user accounts with admin rights will not be able to run commands with root privileges using the sudo tool. For more details, see below the jump.

Read more…

%d bloggers like this: