How to enable text-only boot in newer Fedora versions

Upgrading for the first time to Fedora 10, I was disappointed to see that my runlevel settings did not seem to carry over through the upgrade, and had to hit Esc in order to see the kernel messages.




Fedora 10+ distributions have replaced the anaconda bootloader with plymouth, which is not affected by /etc/inittab, although setting the runlevel will still determine the appearance of the login prompt. In order to disable this bar, you must instead edit /etc/grub.conf or /boot/grub/grub.conf, the former being a symbolic link to the latter.

Remove rhgb quiet from the boot parameters:

title Fedora (2.6.27.5-117.fc10.i686)
 root (hd0,9)
 kernel /boot/vmlinuz-2.6.27.5-117.fc10.i686 ro root=LABEL=/ rhgb quiet
 initrd /boot/initrd-2.6.27.5-117.fc10.i686.img

Fedora 10+ also comes with a pretty animated boot sequence instead of the progress bar. To enable it, you must add vga= with the appropriate framebuffer resolution to the boot parameters. To find the framebuffer resolution, use the following table:

Colours   640x480 800x600 1024x768 1280x1024 1600x1200
--------+---------------------------------------------
256     |   769     771      773      775       796
32,768  |   784     787      790      793       797
65,536  |   785     788      791      794       798
16.8M   |   786     789      792      795       799

To enable the graphical boot in in plymouth, add the vga resolution to /etc/grub.conf. vga=792 is the standard resolution for most modern monitors. Although the xrandr command can show your current screen resolution if you don't know it or it isn't listed, I have had trouble getting plymouth to accept non-standard resolutions, such as those on widescreen laptops. However, the resolution you set will affect only the boot screen and not the GDM/X11 display, so it is purely aesthetic entertainment while you wait for it to boot.

title Fedora (2.6.27.5-117.fc10.i686)
 root (hd0,9)
 kernel /boot/vmlinuz-2.6.27.5-117.fc10.i686 ro root=LABEL=/ rhgb quiet vga=792
 initrd /boot/initrd-2.6.27.5-117.fc10.i686.im

Read Full Post

Enabling the root account in Mac OS X

By default the root account is disabled under Mac OS X, replaced by the first user created during the installation, who although is granted some administrator priviledges, can accomplish very little other than application installation and basic access management. To use many of the UNIX tools or do much with the Terminal, the root account must be enabled.

To enable it, use sudo su while logged in as an administrative user, and if you have not enabled NOPASSWD sudo commands, you will be prompted for your password. Now use passwd
to change the root password; it does not have to be the same as the administrator password.

Once the account is enabled, it will show up as "Other" in the login window.

Read Full Post

Why does SSH refuse my RSA publickey?

After successfully generating RSA keys and copying the public key to the remote authorized_hosts, I have encountered many times a message like this when trying to ssh in:

Executing: program /usr/bin/ssh host
office-minimac, user (unspecified), command scp -v -t
~/.ssh/authorized_keys
OpenSSH_5.1p1, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to office-minimac [192.168.2.103] port 22.
debug1: Connection established.
debug1: identity file /home/drsavoye/.ssh/identity type -1
debug1: identity file /home/drsavoye/.ssh/id_rsa type 1
debug1: identity file /home/drsavoye/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH_4*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'office-minimac' is known and matches the RSA host key.
debug1: Found key in /home/drsavoye/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue:
publickey,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor code may provide more
information
No credentials cache found

debug1: Unspecified GSS failure. Minor code may provide more
information
No credentials cache found

debug1: Unspecified GSS failure. Minor code may provide more
information


debug1: Next authentication method: publickey
debug1: Trying private key: /home/drsavoye/.ssh/identity
debug1: Offering public key: /home/drsavoye/.ssh/id_rsa
debug1: Authentications that can continue:
publickey,gssapi-with-mic,password
debug1: Trying private key: /home/drsavoye/.ssh/id_dsa
debug1: Next authentication method: password
drsavoye@office-minimac's password:

This happens when the permissions of the .ssh directory or any of its items are incorrect. Commonly the mode of the .ssh directory itself will be set to 775 or 777; setting group write permissions on any of the files will cause this effect. The correct permissions of the .ssh directory:

~/.ssh{drsavoye@ushuaia} pts/4$ ls -la
total 40
drwxr-xr-x    2    drsavoye drsavoye  4096  feb 26 08:31 .
drwxr-xr-x    143  drsavoye drsavoye 20480  feb 26 08:31 ..
-rw-r--r--    1    drsavoye drsavoye   408  feb 25 22:01 authorized_keys
-rw-------    1    drsavoye drsavoye  1671  feb 25 22:01 id_rsa
-rw-r--r--    1    drsavoye drsavoye   405  feb 25 22:01 id_rsa.pub
-rw-r--r--    1    drsavoye drsavoye   810  feb 25 22:01 known_hosts

If they differ, use chmod 755 ~/.ssh and chmod 644 ~/.ssh/* to correct them.

Tip: using ssh -vvv {host} will return this verbose output.
Read Full Post

Why do shared Excel workbooks open as Read-Only on OS X sometimes?

Most often seen in office and company environments that use Macs, on occasion a certain user will be unable to edit a shared Office document. Because it's shared, the document keeps track of the UID of each user curently accessing it. If two users possessing the same UID try to edit it at the same time, the second one will get locked out because Office thinks they already have it open.

Since the default UID on Macs is 501 and progresses by 1 for each additional user, this ends up being quite a mess the more Macs that need to access it.

Microsoft's official solution is to use networked user accounts, but this is not always possible depending on what kind of work environment you are in. An easier fix is to change the problem user's UID. Luckily, this is fairly simple using OS X's built-in `dscl` command, although also very simple to make a mistake with.

You can see a list of the currently used UIDs by typing
dscl . -list /Users UniqueID | awk '$2 > 400'

Which will return:

administrator 501
apple  502
drsavoye 503

By using this on all machines, you can immediately see which users match UIDs, even if the usernames don't match.

To change a UID, use dscl . -delete /Users/drsavoye UniqueID and dscl . -create /Users/drsavoye UniqueID 604

Generally you will want to use a higher number to ensure that it does not fall within the range of the Mac's default UIDs. Now you must change the UID on the user's home directory as well. If you miss this step, the user will not be able to access or create any files.

By using ls -l /Users, you will see that the directory "drsavoye" is now shown as drwxr-xr-x 15 503 staff or similar, because the recorded owner (drsavoye) doesn't match the new UID (604). To update it, you can either use
chmod -R drsavoye:staff /Users/drsavoye, or
chmod -R 604:staff /Users/drsavoye

That's it! You should now be able to access all your Office documents. You may have to use `sudo` in order to use dscl if you are not authenticated as root.
Read Full Post

Test Post

blal
fklsfksdfsdlfksd lfmskld mfkls mklsmdfksmd kl
s fsdm fklsm fkmsk mf sfmls fsldmf mslfmsd

skfs
Read Full Post