My father died recently and I've inherited his Mac. I'd love to put it to use in my own life, but I don't want to wipe its brains out just so I can reconfigure it to use in my network, etc. His old files are historically important to me—I trust you can understand my desire to keep them.
I can log in as I had an account on the machine before he passed, but that's about it.
Sincere condolences.
Try this: Mac OS X - Resetting a Forgotten Account Password
The link shows a walk-through of starting up from the Mac OS X installation DVD and using its Reset Password functionality to reset the administrator account's password.
There's further information here: Mac OS X: Changing or resetting an account password
If you don't want to make any changes to the mac, a little known feature called Target Disk Mode might make it easier.
If open firmware password has not been set, you can try entering single user mode by pressing apple-s during boot. Then you should be able to do anything you want, since you will be root.
See this apple support document.
I recommend using this capability to make all your father's files readable by your normal user account, then backup all his files and do a fresh reinstall.
If your account is an administrator account. You can open up Terminal.app and type
sudo passwd root
You will be prompted to enter a new root password.
If you don't have administrator access, you can reset the root password using your osx installation cd. Instructions are here.
EDIT: Node's link is better.
Boot the computer with a BSD or Linux CD and mount the filesystem.
If the machine is running leopard or higher you can actually force
any mac to create a new administrator account by simply deleting one file.
Simply boot into single user mode, (hold command + s when booting up)
once in single user mode, mount the file system using mount -uw /
then input rm /var/db/.AppleSetupDone
restart the machine.
This works by removing the check .AppleSetupDone so it tricks the
mac into replaying the setup assistant on boot.
Else, you can do something very similar to older macs by again booting up into single user mode, except this time inputting the following (line by line)
mount -uw /
cd /private/var/db/netinfo
mv local.nidb local.old
rm ../.AppleSetupDone
exit
If you can access the files in question, then the first thing to do would be to back them up...
FWIW
assuming your account has admin privileges, boot the machine and enter your password; then use the Finder to navigate to his user folder (/Users/name-he-used-on-the-mac); his subfolders will have a little red locked symbol.
you can either copy/paste them in the finder (you will be prompted for your password), or
you can open terminal and ditto them:
sudo ditto <his files> <directory where you want the copies>
at which time you will be prompted for your password.
Related
I recently changed my username in Windows 10 and I just discovered that all folders and files in my profile folder are now write-protected. I also can't remove the write-protection.
The profile folder is still named by the older username. Is there a way to fix this or do I have to change my username back?
Sure, had that user password or some kind of key? create a live usb with Hiren's boot, open NT Password and you can solve it, there are times that usually happens and with that tool, in the cases that have happened to me, it has worked.
Regards
PD: Download it from here, you will have to save it on a USB, also you have the steps: https://www.hirensbootcd.org/download/
When I install Cygwin, the default location is c:\cygwin and after I open a Cygwin terminal, it creates my home folder in C:\cygwin\home\ which the Everyone group has read access to by default. So, if I create a diary in vim and save it to my profile, all users of the computer I'm logged on to can read my diary. Obviously this is not the default option for normal Windows profiles, so I'm wondering what the logic is behind Cygwin's default home directory permissions, so I can use it the way it is meant to be used. Thanks!
There are differences between the permission structures of windows and cygwin.
You can protect your diary by specifying its permission in windows using right click.
You can then check its permissions in cygwin using:
ls -l diary.txt
chmod 0600 diary.txt
ls -l diary.txt
Then login the same machine as a different (test) user and see if you read the file under windows, and in cygwin.
For people interested in this topic, it probably goes back to a setting called UMASK on linux, which specifies default permissions for new files. The default value of "022" means "take away no permissions from the owner, and take away write permissions from the group and the rest of the world" which means that file owners have full access, everyone else has read access.
They say it's to make it easier to share files with other users. I say it's obvious that this logic predates times when we had web browsers and other tools capable of saving passwords to disk.
I'm confused about setting up Jenkins slave on Mac. Google seems to have a great answer for java web start option (https://blog.codecentric.de/en/2012/01/continuous-integration-for-ios-projects-with-jenkins-ci/), however can someone clarify steps for setting up jenkins slave on mac with ssh start option.
Currently jenkins master is on Centos. As I understood, to make a slave on Mac you should:
1. Go to Mac and create a new full-fledged sudo user for jenkins with home folder where agent itself will reside.
2. Set up node as ususal linux node in Jenkins web interface with login|pass for this user.
3. Restrict your mac build to this node.
However I'm not sure if first step is right - do i need to set up jenkins user by hand with elevated privileges, ability to log onto machine, etc. Perhaps it's possible to create a "hidden" user - if that is so, can someone help or point to good manual for this? I'm new to mac terminal, so not sure if steps all the same as linux or different.
Thank you.
Just finished setting up my Mac mini slave for ssh access. Lots of old tutorials and ones with unnecessary information. I had to reboot my mini to start over again and this time it worked.
To put it quickly (this is all through terminal/command line, no Ubuntu nothing else):
Create ssh private and public keys with ssh-keygen. In my case keys were given to me with -C "name" but no passphrase and with file names of id_rsa and id_rsa.pub. Keep private (non .pub) key to be used by Jenkins Credentials later and for testing purposes while verifying things are working for ssh connection without having to relaunch Jenkins agent, the private key should be kept in the /Users/<username>/.ssh directory and readable permission and ownership of the user of local test host if that's how I'm testing it
mkdir .ssh in remote Mac mini slave's /User/jenkins/ directory
on Mac mini make sure owner of .ssh directory and any sub directories or files are jenkins and NOT root (sudo chown ...).
make sure permissions of .ssh directory and any sub dirs or files are read and writeable (if you haven't set ownership properly, in order to change permissions you will be required to use sudo. If you are using sudo to set permissions, you haven't properly set ownership to the jenkins user)
allow remote login in the Mac mini system preferences -> Sharing -> check Remote login and allow Administrators and static IP -> Network -> TCP/IP -> DHCP with manual or completely manual
on test host/local machine (non Mac mini) terminal and command line ssh jenkins#static.ip.address.of.MacMini to make sure you can ssh into remote Mac mini with password authentication. You may get a request to okay the new host (at remote Mac mini's IP address).
then logout and in local machine use ssh-copy-id -i to copy contents of id_rsa.pub (whether its in .ssh or wherever) to authorized_keys found here.
this will automatically generate authorized_keys file in .ssh directory
make sure authorized_keys file is also of proper permission
in Jenkins manage nodes. Create a new node. Add credential and make it ssh username with private key. Username: jenkins. Private key: enter directly. String should be copied from local machine test host private key (pbcopy<~/.ssh/id_rsa) including the ==== begin and end private key ====== parts and then save.
Then on new node configuration No need for toolkit. Remote root directory: /Users/jenkins. Host: Mac mini's static IP address. Host Key verification strategy: Manually Trusted Key verification strategy. Check require manual verification of initial connection
upon first connection attempt if you don't have JDK setup and running then do so. I downloaded Java 8 Stack Exchange Development Kit and once I confirmed it was installed on Mac mini with javac-version and java-version I launched agent again and authenticated no problem.
My mistakes from reading old tutorials were:
trying to remove the need for passwords in /etc/ssh/sshd_config. This was completely unnecessary
Also, I may have not paid attention to the owner and/or screwed up permissions of .ssh, .ssh/authorized_keys & .ssh/id_rsa in remote and my local machine as well.
Initially I deleted the ===== Begin private key and ======End private key when I manually entered the private key when creating the credential in jenkins. Those should be included. The file of id_rsa should be left as is.
You do need a user on the Mac which the Jenkins master will use to ssh in. But this is exactly the same as setting up a Linux slave.
Whether the user needs elevated privileges depends on what you want Jenkins to do with the account.
You also need to log into Mac from the console using an admin user and turn on remote login in the Sharing panel of System Preferences. In the same panel you can restrict the remote login to specific users or allow all users to log in.
If I were you, I would create a normal user for Jenkins using the Users and Groups panel in System Preferences. Creating a hidden user using command line tools is possible, but it is a bit involved. If you really want to go there, you can check how postinstall script in Jenkins Mac installer creates a user named jenkins:
https://github.com/jenkinsci/packaging/blob/master/osx/scripts/postinstall-launchd-jenkins
Environment : Eclipse Indigo, Ubuntu 11.04, Subclipse 1.6
SVN Clients : Subclipse, RabbitVCS
I'm connecting via svn+ssh. My URL looks like :
svn+ssh://[MY NAME]#[MY DOMAIN]/[PATH]
I can connect to the repo just fine. The problem is that every time I try to communicate with the repo, it prompts me for a password. Really annoying!
I get the impression that SVN has the ability to cache passwords -- I've read that's what the ./subversion/auth folder is for. However, my ./subversion/auth folder contains four empty folders.
I've experienced this behavior with both Subclipse and RabbitVCS.
Is there any way to force SVN to cache my credentials?
You need to use Public Key Authentication with SSH:
https://help.ubuntu.com/community/SSH/OpenSSH/Keys
It will enable you to used svn over ssh without entering a password every single time, with help of a common SSH agent.
Subversion itself caches credentials only to servers using HTTP/DAV.
Maybe this may help to someone. Check whether ~/.subversion folder is owned by wrong user, so it may be read-only to user who is using it.
sudo chown -R your_username:your_group ~/.subversion
I am creating a graphical installer that should run on Linux. Installing should consist of copying files to some places in /usr. Currently the installer is written in Python.
How can I escalate the privileges of my installer when I need to copy files? I looked at PolicyKit but
a) there doesn't seem to be a generic "install files" action-id for PolicyKit
b) of the action ids I can use, I don't think they are standard across distros
I also looked at PAM and I have code that uses libpam but I can't seem to do anything with it. After authenticating my user (by providing username and password) I don't have write access to /usr. I tried changing my user with os.setuid(0) after authentication but I get an error from the OS.
Also, strangely, it doesn't seem to matter what service I provide to pam_start. As long as the username and password are correct I can pass anything I want. I see I have /etc/pam.d/sudo. The below code is simplified, the password is correctly stored in a pam_conversation object and I do pass a handle object.
pam_start("my_user", "my_pass", "sudo_garbage_12345");
works just as well as
pam_start("my_user", "my_pass", "sudo");
That is, they both succeed.
As a last resort I can probably execute gksudo or kdesudo but I don't want to be tied to those programs. Requiring users to invoke my installer with sudo is a (very) last resort.
You might be better off wrapping RPM with a front end that takes the user options and invokes RPM to do the hard work. This also gives you infrastructure for managing dependencies and plays nicely with the existing package management system. If you need to run on a .deb based system (Debian or Ubuntu) you may also need to consturct a .deb and put some mechanism in the front end that works out which package management system is active.
Granting random users access to root privilege is generally viewed as bad form on Linux or Unix systems (or any multi-user system for that matter) as it is a significant security risk. However you do have the option of letting the user install it under their home directory (~/bin) if they don't have root access or sudo permissions that allow them to write to system areas. In this case you can require them to install it as root if they want to install in /usr/bin but permit them to install it under their home directory for their own use if they don't have root privileges.
For a graphical installer, stick with a graphical environment. Use gksudo or kdesudo if they are available, otherwise fail with an error dialog saying they need root. People (newbies in particular) will download your installer and double-click to launch it from their desktop, and you need a graphical way to ask them for their password. You don't want to pop open a terminal on them.
Given that, don't do sudo for them even if they are running from the terminal. Just output an error saying you need root and exit. If the user is already at the command prompt (like I most likely would be), I already know how to sudo or su myself into root if I want to do so. I promise you you will most likely ruffle some feathers if you attempt to make an experienced user root when they can do it themselves.
If you INSIST on doing a sudo yourself from within your installer, for God's sake please force a 'sudo -K' before you do to remove the previous timestamp. If you don't do this, and I have sudo'd recently, you will run your installer with me as root without my knowledge (since I don't expect that to happen). A 'sudo -K' will force a prompt that I can then decide whether I want to proceed as root or not.
The best way in this case is to use su within your program. Redirect inputs/outputs and you're good to go!