uudruid74

Sounds like the examples need to be removed then

yes

The moment I do an 'su'

Anyone see anything wrong with this line in /etc/login.defs ? MOTD_FILE /etc/motd Here's what I get: configuration error - unknown item 'MOTD_FILE' (notify administrator)

I don't need an Android app. I'm trying to get jack compiled for Android. Its been ported, I just need to compile it. Although ... it would seem it not going to be easy!

OK ... I'm pulling my hair out and I feel stupid ... especially since I'm all out of hair. *doh!* less is not interpretting the files I give it. For example, if I give it an HTML, it just shows me the raw HTML than formatting it. Its supposed to do this via the lesspipe program (installed) and the LESSOPEN environment variable, which is set and exported. lesspipe isn't getting run. Its in the PATH and I can run it manually. Anyone else seeing this?

Very odd. Just installed it to 2 systems. It installed two versions. Version 1 outputs in s format suitable to be read by the shell. Version 2 does not. Odd change. Seems like going backwards.

Someone has done it! Awesome. Wish it was the default rather than an odd on, like if you don't have the variable specified, emerge would just look at the flags and go, but... we don't always get what we want! Thanks for mentioning that package though. Trying it now

And what I was confused about is WHY I should have to make such a change. This should be set up one way or the other, not have packages tell me to change my directory structure back and forth. Its not making any sense.

I have an SDK update manager on my desktop, but it mainly installs Java libs and its a GUI tool. I just want the cross compiler, not a dull Android ask, and must be able to install it from a shell. There is no GUI on the devel box. I'd prefer not to break the package manager, but if I have to I will. Do have a URL for the download? I was thinking of using a deb or rpm package and just manually installing it.

There should be some option that peeks at /proc/cpuinfo for all the flags to see what your CPU supports and uses -march=native for the usual architecture build. No good if building for another host, but most people are building on their own box.

What's the status of crossdev? I'm getting a message to convert /etc/portage/package.mask to a directory. My magic wand is broken. WTF am I supposed to do to the file? And IRC is saying crossdev is broken permanently. I just want to cross-compile 1 stinking package (need not be an ebuild, I can build from source tarball) so I can stick it on my phone (its rooted). Whats the fastest way to get a cross-compiler installed? I can build it manually. I did it about 15 years ago but I can't remember how the F&^% I did it!

Or -j1 to run 1 at a time, and if the BIOS lets you underclock, do it. Also try to set your CPU governor to something slow and boring like powersave. The slower it runs the cooler. If you don't have a tool to set the governor, and you have support for cpu frequency scaling in your kernel,let me know and I can paste you a small script to set it that doesn't need any special tools.

If Linux is randomly shutting down its a hardware problem. Also, I can tell you came from a Windows platform. Linux guys generally won't recommend things like rebooting (it doesn't fix things just hides the problem), or reinstalling. Reinstalling it again is redundant unless you changed something, and even then, maybe not.

All good advice, the only thing I would add is to limit how much you tackle at once. Some of that perl stuff you could emerge separately so that you have a smaller chunk to deal with. Also, I would tackle getting X and getting it working before you worry about nvidia-drivers. I'm guessing thats the binary? That will avoid a lot of hassles you could likely defer to later, such as having 32-bit compatible binaries. I still don't understand why the game companies complain about Linux not being advanced enough for them, but all the games and drivers require 32 bit libraries. Linux was the first system to go pure 64 bit, and I don't think many games will work at all on a system so old that it can't run 64 bit pointers. Maybe I'm missing something? When you have problems, break the problem down into chunks that are easier to manage. Reduce the number of variables in your equation.

OK ... here's a question for you. How do you detect if a user is using a handheld? In most cases, you don't need to know. But what if you actually needed to know to hide certain elements, such as instructions to press a particular key combination or something that made no sense on a handheld. CSS defines @media handheld for this purpose, but browsers don't support it! I ended up making 2 CSS files, one I dropped into my /m folder using the above. This lets nginx do the browser detection and return which CSS sheet to give to the user. 99% of the CSS is a different file which is symlinked to appear in both directories. It may not be an elegant solution, but if anyone knows of another way to do handheld detection, I'd love to hear it! And I like the nginx hack better than using javascript. This is more or less pure CSS.

Here's another stupid admin trick ... How often do you have about a dozen shell windows open? Let's add two capabilities to make that easier. These are controlled with a line that looks like this in the script: export PROMPT_COMMAND="shareHistory; testWindow" You can simply remove the feature you don't want from your PROMPT_COMMAND, or change it on a window-by-window basis if you like. shareHistory - Consolidate the bash history so that it is available through any bash that your username controls. The history will sync after every command. The only drawback is that it's AFTER every command, so you might want to hit enter if you just switched windows to ensure that the commands you just used in the other window are available in this window. Hit ENTER to sync up, then use up-arrow, history, or ! commands as if you never swiched windows. fixTitle - This one happens as part of the testWindow command below. It updates the window title to the command you just ran so that you always know whats running in that window. testWindow - You probably switched windows because you are waiting on something to finish, like an emerge. Wouldn't it be nice to know when it's done? This command will look and see if its currently on top and if not, it will issues a notification to your desktop to let you know the last command finished. It even selects an appropriate icon. Its silent as long as window is on top. This is sort of a hack since bash doesn't know anything about your window stack. Instead, a couple commands are aliased to look at the window that currently has focus (which should be itself since you are typing the command!) and records this. You shouldn't use commands that record the window in a script. You can also force it to remember the window with the new command n. Also, the testWindow functionality is set up to not try to remember the window when the script starts. This is because your bash profile starts to run before the window is open and gets focus creating a race condition. You have to specifically turn on the feature with 'n'. I've also aliased 'ls' and 'emerge' to turn this on as well (and record the window via 'updateWindowId'). None of the fixTitle or textWindow features work until you use one of these commands. To use, save the following script as /usr/local/bin/windowtricks.bash #!/bin/bash #- #- This is to display notifications when you aren't watching the window #- and updates the window title with the currently running command. #- The command is reset when it finishes, unless the window is on top. #- In this case, the window title is kept so you can find it. You #- may use the 'n' command to manually reset the window title. #- #- We should only update the WindowId when the window has focus! #- This means the first update can't be inside .bashrc #- #- The new 'n' command updates the 'notify' and resets title to $SHELL #- #- source this file from your .bashrc #- shopt -s histappend alias n='updateWindowId; fixTitle; initTrap' #- These commands will automatically call n to turn on the features alias ls='n; ls --color=tty' # alias cd='n; cd' alias emerge='n; emerge' #- keep this info resetTaskName() { LC_TASK=$(basename ${SHELL}) } #- need to remember this updateWindowId() { LC_XWINDOWID=$(xdotool getactivewindow) #resetTaskName if [ -z "$LC_NAME" ]; then LC_NAME=$(xdotool getwindowname $LC_XWINDOWID) fi } #- actually set the window title fixTitle() { #- If we have a 'screen' type terminal, name the screen, not the window case $TERM in screen) echo -ne "\033k${LC_TASK}\033\\" ;; xterm|xterm-256color|xterm-color|Eterm|aterm|rxvt|kterm|rxvt-unicode|gnome|interix) echo -ne "\x1b]0;${LC_NAME}: ${LC_TASK}\x07" ;; esac } #- get command for title autoTitle() { case $BASH_COMMAND in fixTitle) ;; testWindow) ;; updateWindowId) ;; getLastCommand) ;; sendNotify) ;; *) LC_TASK=$BASH_COMMAND fixTitle ;; esac } #- grab from history getLastCommand() { LC_TASK=$(history 1 | cut -c 8-) LC_ICON=$(basename $LC_TASK 2>/dev/null) if [ -z "$LC_ICON" ]; then LC_ICON="utilities-terminal" else #- FIXME: This is a bad/slow hack. eval $(locate $LC_ICON.desktop | xargs cat | grep Icon | head -1 | sed 's/Icon/LC_ICON/') 2>/dev/null fi } #- notification of task completion sendNotify() { getLastCommand notify-send -t 10000 -i "$LC_ICON" "Task Complete in $LC_NAME" "$LC_TASK" } #- test to see if window is on top testWindow() { LC_ACTIVE=$(xdotool getactivewindow 2>/dev/null) if [ -z "$LC_XWINDOWID" ]; then return 0; fi if [ "$LC_ACTIVE" != "$LC_XWINDOWID" ]; then #- This command is forked because it takes too long sendNotify & disown 2>/dev/null else #- comment these 3 lines to keep last command in title resetTaskName #- above and this one fixTitle #- and this one fi } #- This trick shares history in all open bash windows shareHistory() { history -a history -c history -r } #- the magic! Executed when prompt is displayed export PROMPT_COMMAND="shareHistory; testWindow" #- some magic for updating window title initTrap () { if [ -z "$LC_INIT" ]; then #- These commands update the windowid in case #- our shell moved from one window to another alias ls='updateWindowId; ls --color=tty' alias cd='updateWindowId; cd' #- The rest we just unalias unalias emerge LC_INIT="DONE" trap autoTitle DEBUG fi } Now change your .bashrc and add a line like this at the end. source /usr/local/bin/windowtricks.bash Enjoy!

Oh, it wasn't the point to do a whole website. That's what /joomla was for. Yes, I could make the whole site in joomla, but that still leaves little details like custom error pages. I wanted a method that was simple, no javascript, no external frameworks to learn, that would handle the static /index.html and error pages and anything else that I felt I wanted to add outside the joomla framework. Yes, if designing a large website, its better to use dynamic content rather than colorful webserver tricks (hence why the title is "tricks" and not "best practices"). However, I hope people will make sure that they handle that "Request Desktop Site" checkbox in whatever solution they choose. I should be able to click that checkbox and turn my phone sideways to get the exact same site as on a desktop. In fact, things like error pages should display properly on a mobile but shouldn't use javascript or contain any sort of dynamic content. I'm really thinking of adding a "Contact" page that is outside the Joomla CSS. Too often I see sites that are broken, and you can't get into the site to reach the Contact page to tell the owner its broken. Some things should be simple, and I'm NOT going to learn any of those frameworks you mention. Thats for web developers. I'm not!

You had the boot order right the first time! Never doubt yourself. Bootloader loads kernel and initrd, a temporary root filesystem with more drivers/modules so that it can autodetect the root filesystem (which could means raid drivers filesystem drivers, nfs, etc) The kernel loads initd and initd runs OpenRc scripts and anything else needed to start up the system.

If you use a content management system for your site, it probably already deals with mobile systems. But, what if you have parts of your site that aren't in a CMS, or you do your site by hand? Well, it would be nice to either redirect from www.example.com to m.example.com, or (my preference), to redirect to a subdirectory. I like the subdirectory approach because I can easily share content with the main site via symlinks (such as the content management system). Normally, this isn't a nice thing to do to your caches since any caches along the way won't know that the symlinked files aren't the same, but if you can solve that, let me know. The following method redirects the user if they are on a mobile browser, but still allows them to use the "Request Desktop Site" feature. Just include the file in your tengine or nginx server configuration. The actual rewrite is done at the end. Scroll to the bottom and you'll see the line to edit. I tried to attach the file, but it said I'm not permitted to upload files of that type. Cut-Paste or email me and I'll send it to you. >#- This file for doing redirects based on mobile detectionset $mobile_rewrite do_not_perform;#- chi http_user_agent for mobile / smart phonesif ($http_user_agent ~* "(android|bb\d+|meego).+mobile|avantgo|bada\/|blackberry|blazer|compal|elaine|fennec|hiptop|iemobile|ip(hone|od)|iris|kindle|lge |maemo|midp|mmp|netfront|opera m(ob|in)i|palm( os)?|phone|p(ixi|re)\/|plucker|pocket|psp|series(4|6)0|symbian|treo|up\.(browser|link)|vodafone|wap|windows (ce|phone)|xda|xiino") {set $mobile_rewrite perform;}if ($http_user_agent ~* "^(1207|6310|6590|3gso|4thp|50[1-6]i|770s|802s|a wa|abac|ac(er|oo|s\-)|ai(ko|rn)|al(av|ca|co)|amoi|an(ex|ny|yw)|aptu|ar(ch|go)|as(te|us)|attw|au(di|\-m|r |s )|avan|be(ck|ll|nq)|bi(lb|rd)|bl(ac|az)|br(e|v)w|bumb|bw\-(n|u)|c55\/|capi|ccwa|cdm\-|cell|chtm|cldc|cmd\-|co(mp|nd)|craw|da(it|ll|ng)|dbte|dc\-s|devi|dica|dmob|do(c|p)o|ds(12|\-d)|el(49|ai)|em(l2|ul)|er(ic|k0)|esl8|ez([4-7]0|os|wa|ze)|fetc|fly(\-|_)|g1 u|g560|gene|gf\-5|g\-mo|go(\.w|od)|gr(ad|un)|haie|hcit|hd\-(m|p|t)|hei\-|hi(pt|ta)|hp( i|ip)|hs\-c|ht(c(\-| |_|a|g|p|s|t)|tp)|hu(aw|tc)|i\-(20|go|ma)|i230|iac( |\-|\/)|ibro|idea|ig01|ikom|im1k|inno|ipaq|iris|ja(t|v)a|jbro|jemu|jigs|kddi|keji|kgt( |\/)|klon|kpt |kwc\-|kyo(c|k)|le(no|xi)|lg( g|\/(k|l|u)|50|54|\-[a-w])|libw|lynx|m1\-w|m3ga|m50\/|ma(te|ui|xo)|mc(01|21|ca)|m\-cr|me(rc|ri)|mi(o8|oa|ts)|mmef|mo(01|02|bi|de|do|t(\-| |o|v)|zz)|mt(50|p1|v )|mwbp|mywa|n10[0-2]|n20[2-3]|n30(0|2)|n50(0|2|5)|n7(0(0|1)|10)|ne((c|m)\-|on|tf|wf|wg|wt)|nok(6|i)|nzph|o2im|op(ti|wv)|oran|owg1|p800|pan(a|d|t)|pdxg|pg(13|\-([1-8]|c))|phil|pire|pl(ay|uc)|pn\-2|po(ck|rt|se)|prox|psio|pt\-g|qa\-a|qc(07|12|21|32|60|\-[2-7]|i\-)|qtek|r380|r600|raks|rim9|ro(ve|zo)|s55\/|sa(ge|ma|mm|ms|ny|va)|sc(01|h\-|oo|p\-)|sdk\/|se(c(\-|0|1)|47|mc|nd|ri)|sgh\-|shar|sie(\-|m)|sk\-0|sl(45|id)|sm(al|ar|b3|it|t5)|so(ft|ny)|sp(01|h\-|v\-|v )|sy(01|mb)|t2(18|50)|t6(00|10|18)|ta(gt|lk)|tcl\-|tdg\-|tel(i|m)|tim\-|t\-mo|to(pl|sh)|ts(70|m\-|m3|m5)|tx\-9|up(\.b|g1|si)|utst|v400|v750|veri|vi(rg|te)|vk(40|5[0-3]|\-v)|vm40|voda|vulc|vx(52|53|60|61|70|80|81|83|85|98)|w3c(\-| )|webc|whit|wi(g |nc|nw)|wmlb|wonu|x700|yas\-|your|zeto|zte\-)") {set $mobile_rewrite perform;}set $force_dt_cookie "";if ($args ~ 'desktop=true') {set $mobile_rewrite do_not_perform;set $force_dt_cookie "desktop=true";}add_header Set-Cookie $force_dt_cookie;if ($http_cookie ~ 'desktop=true') {set $mobile_rewrite do_not_perform;}location /m {error_page 404 /m/error/404.html;}#- redirect to /m except /m, /mail, /joomlaif ($mobile_rewrite = perform ) {rewrite ^(?!(/m|/joomla)+) /m$request_uri? break;break;}#- To redirect to m.example.com, change above rewrite to# rewrite ^ https://m.example.com$request_uri? break; That's it! I just put my mobile files in the /m directory of the server.

Most of that is simple (dunno about Xen). Build a test system and then generate the binary packages, either from the running system or a subsequent rebuild with -e -B. You can then install it all to the new USB drive with -g --root . Not sure if I missed a step. You might also want to look at the pentoo project. Its a similar tool based on gentoo for penetration testing. For rescuing a system, I highly recommend safecopy instead of dd. Its very smart about avoiding sections of a failing disk that have physical errors. It will come back and read them later, even using low-level access if it can. Basically, where dd would die, this will skip that section to avoid doing more damage and then come back later. http://safecopy.sourceforge.net/

Anyone look into Android's init daemon? Its actually kind of interesting.

OK, you've got your SSL certificate and you have tengine or nginx setup, but you need it secure. After all, you've heard of all the recent DH attacks, BEAST, CRIME, FREAK, Heartbleed and others, right? Is your system already secure? Test it! Check out The SSL Labs Test Site. I'm getting an A+ rating! The following assumes tengine, but nginx is exactly the same, just s/tengine/nginx/g; Need a certificate? OK - I highly recommend StartSSL. It's FREE! These guys will step you through the process by following the instructions on their site. If you have problems, the tech support via email is instantaneous and incredibly professional. My cert was the free variety, but if I ever upgrade, I will go to them because the support (to a non-paying customer no less) was so good. OK ... Make a file /etc/tengine/ssl.conf (or equiv for nginx): >#- Ports to listen on, all addresses, IPv6 and IPv4listen [::]:443 ssl;listen 443 ssl;#- Support current SSL standards and options onlyssl_session_cache shared:SSL:10m;ssl_session_timeout 10m;ssl_protocols TLSv1 TLSv1.1 TLSv1.2;ssl_prefer_server_ciphers on;ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";ssl_session_tickets off;ssl_stapling on;ssl_stapling_verify on;#- And some security related headersadd_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";add_header X-Frame-Options DENY;add_header X-Content-Type-Options nosniff; Now, go into your sites-available and in the server{} configuration for the site you want to include SSL, add these lines: >include /etc/tengine/ssl.conf;ssl_dhparam /etc/ssl/tengine/dhparam4096;ssl_trusted_certificate /etc/ssl/tengine/startssl_trust_chain.crt;ssl_certificate /etc/ssl/tengine/ssl-unified.crt;ssl_certificate_key /etc/ssl/tengine/ssl.key; Now, there are 4 files here for SSL in addition to the one we just included. Let's look at where they come from. First, you should have a certificate file (ssl.crt in the following), and a key for that file (private_ssl.key). The CRT begins with "-----BEGIN CERTIFICATE-----", but you will need to view this in vi, not less (less will try to decode many of these files). Your private key is password protected (the key is "-----BEGIN RSA PRIVATE KEY-----" followed by a line that says ENCRYPTED). Since you probably don't want to issue a password every time you start your server, let's fix that first. >openssl rsa -in private_ssl.key -out /etc/ssl/tengine/ssl.key Easy enough? And we have one of our lines done. 3 to go! The next is to create a chain of certificates back to the root. For StartSSL, you download their cert: >wget https://www.startssl.com/certs/class1/sha2/pem/sub.class1.server.sha2.ca.pem Then make the file you need with your cert and theirs. Here's your next 2 files! >cat ssl.crt sub.class1.server.sha2.ca.pem > /etc/ssl/tengine/ssl-unified.crtcp sub.class1.server.sha2.ca.pem /etc/ssl/tengine/startssl_trust_chain.crt Now, the final command for the final file: >openssl dhparam -out /etc/ssl/tengine/dhparam4096 4096 4096 might be overkill, but 1024 is the minimum and you might as well go all out just in case 1024 gets broken next month! Be sure all these files are secure! >chmod 0600 /etc/ssl/tengine/* Delete originals, clean up, then restart tengine. Next I'll cover gzip compression, detecting mobile client, and joomla configuration. Any particular one anyone wants to see first?

In general, you wont be adding kernel level drivers. You can go into the kernel source and do a make menuconfig, select some additional modules and then do a make modules and make modules_install. This wont build modules that are already built or the kernel. However, most people just build all the modules they might need and don't mess with it anymore. When it comes to binary video drivers, they are built against the existing kernel sources so that they can build a module If you update your kernel, you will need to update those modules at the same time or you lose your GUI. I don't recommend using proprietary binary video drivers. Its actually possible to load modules built for one kernel version into a different one, but its so error prone and kinda pointless since the source for them all is right there. Much safer to rebuild the modules with the kernel. Technical (not totally accurate, but here's the simple version): the modules are placed in a /lib/modules/{kernel version}/ directory and then depmod is run which looks through the module headers to create a module database of supported device ids and what module is available for each device. The udev daemon listens to kernel gernerated insertion events and then loads the right module via modprobe based on the device ids from the kernel, the module database, and user preferences. It also generates the correct /dev entries for the new device.

<-- likes Gnome 3. Takes a min to get used to, but I'm enjoying it. And I have a touchscreen, so that makes a difference.