So,
I have some books that need to go back to the library. I can't renew until I replace 2 books that got water damage (I spilled my drink in my backpack). So, all of my items are going to come due real soon.
The only problem: I got a bunch of cool (programming), books from the library--and I'm not ready to give them up!
Except I must return them--especially if I don't want to accrue any more fines.
__
I've been wanting to get a scanner for a while. I had no intention of paying full price for one at amazon.
In the united states, there exists a type of store known as: "Thrift stores." They specialize in the sale of used goods. However, in the United States, they have a special contract with the state government in which they operate, where individuals may recieve a "Tax refund," when they "donate," items which they no longer want.
This is an ingenious business model. The thrift store gets a inexhaustible supply of inventory, essentially for free. Furthermore, the population (generally middle-class and up), have incentive to donate (and thereby provide the supply), in order to receive a "Tax refund." (The person who donates gets a refund slip, come tax time, they can get the monetary value of there donated items back.)
So, I went to my local thrift store (Goodwill), and picked up a Lexmark x1270. I didn't realize until a few moments ago that this thing was made 9 years ago. However, my requirements were slim: I did not require the printer functionality, only the scanner.
The process is ridiculously simple: I simply plugged it in, loaded xsane, and I was able to scan!
$5 well spent :)
Diego
Sunday, August 9, 2015
Thursday, July 2, 2015
How to root QMV7A
Hello everyone!
I just recently obtained a semi-new/used tablet, which I have become quite fond of. I tried rooting the device using differnt methods I found online, but encountered some trouble in the process. Hopefully this guide will clarify the process.
Here is my device info (with the important info in bold font):
Model number: QMV7A
Android version:
4.4.2
Baseband version:
ALT3100_04_05_06_00_94_TF
Kernel version: 3.4.67
wormboss@midgard #1
Sat Dec 20 01:00:16 CST 2014
Build number:
ALPS.KK1.MP5.V1
SW Version:
MV7A_41D37_442A
HW Version:
D3A
I utilized kingoroot for my method.
1. Enable the "Unknown Sources," option in the following menu:
- Settings > Security > Device Administration > Unknown Sources
2. Download the KingoRoot APK from the following link:
- d.kingoapp.com/website/KingoRoot.apk
3. Open the downloads widget from the app menu and select the KingoRoot.apk file (confirm installation of file)
4. Select the Root button and start the rooting process
If rooting was succesfull, the progress bar should fill to %100 and you should see a message stating the device was succesfully rooted!
You can download an external app called "Root Checker Basic," or you can also verify root by installing a terminal app and attempting to SU to root :)
Diego
I just recently obtained a semi-new/used tablet, which I have become quite fond of. I tried rooting the device using differnt methods I found online, but encountered some trouble in the process. Hopefully this guide will clarify the process.
Here is my device info (with the important info in bold font):
Model number: QMV7A
Android version:
4.4.2
Baseband version:
ALT3100_04_05_06_00_94_TF
Kernel version: 3.4.67
wormboss@midgard #1
Sat Dec 20 01:00:16 CST 2014
Build number:
ALPS.KK1.MP5.V1
SW Version:
MV7A_41D37_442A
HW Version:
D3A
I utilized kingoroot for my method.
1. Enable the "Unknown Sources," option in the following menu:
- Settings > Security > Device Administration > Unknown Sources
2. Download the KingoRoot APK from the following link:
- d.kingoapp.com/website/KingoRoot.apk
3. Open the downloads widget from the app menu and select the KingoRoot.apk file (confirm installation of file)
4. Select the Root button and start the rooting process
If rooting was succesfull, the progress bar should fill to %100 and you should see a message stating the device was succesfully rooted!
You can download an external app called "Root Checker Basic," or you can also verify root by installing a terminal app and attempting to SU to root :)
Diego
Sunday, February 15, 2015
Linux Bonding Channel Driver, on Slackware P3
Basically, the bonding driver included in the stock 14.1 Slackware kernel (3.10.17), still supports using the ifenslave tool.
Unfortunately, there isn't a current slackbuild in either's Slackware official package repo nor the slackbuilds repository which has a Slackbuild for ifenslave.
So, you're left building it from scratch as described in the source file ifenslave.c (/usr/src/linux/Documentation/networking/ifenslave.c):
compile-command: "gcc -Wall -Wstrict-prototypes -O -I/usr/src/linux/include ifenslave.c -o ifenslave"
When I was initially attempting to use the bonding driver, it was on my Poweredge 750 (arch: i686). For whatever reason, I could never get this source file to actually compile the binary ifenslave w/o encountering a build error.
This prompted me to look for an alternative. All the documentation I've seen in setting up bonding in Slackware walk you through this step first. In the major distros, ifenslave is either already included in the official repository, or bonding is integrated into the init script.
After some searching I finally came across an alternative: Vincent Batts posted a Slackbuild for ifenslave! It was hidden in the discarded directory, I believe it was for Slackware 12. It built just fine on my system!
(I later discovered what Vincent employed in his Slackbuild that actually allowed me to build ifenslave properly on my 14.1 x86 poweredge: the arch variable wasn't set via a case statement tied to uname--as is normally done-- it was hardcoded to 386.)
I was able to load the binary, initialize a bonded interface w/ ifconfig, and successfully utilized ifenslave to set the slave interfaces under the bond.
I've received Vincents permission to become the maintainer of the Slackbuild for the current release. I've modified it w/ enough core functionality to enable a Slackware installation to easily configure bonding. My difficulties in my journey to enable bonding in Slackware compelled me to create a solution that would bring this much needed functionality into Slackware into a simple installable package.
However, there is a caveat. Mainly, the current version of the Linux Bonding Driver (in the current stable kernel), no longer officially supports ifenslave--its use is now considered obsolete. This is sad, because the dev's reasoning is that a) most distro's include bonding functionality in the init scripts (a la RHEL), or b) in lack of such support you can always rely on creating a bond via the sysfs interface (/sys/class/net/bondX).
That being said, Slackware 14.1's kernel (3.10.17), still uses the older bonding driver, which supports ifenslave.
In fact--the current bonding driver doc mentions ifenslave will still function w/ the bonding driver and can be utilized. They just no longer support it and are in favor of the sysfs interface instead (which actually does provide more functionality in the bond initialization process).
So, I realize there is a need for this Slackbuild, although it will only be useful to a small audience (14.1). I'm not sure which kernel current is using, or if the bonding driver in that release still supports ifenslave or not.
Edit: I just checked kernel 3.14.29 (utilized at the moment in current); this kernel utilizes the updated bonding driver which does not officially support ifenslave.
To continue on though, ifenslave isn't the only thing we need to overcome in slackware. Sure, you could create a bond manually by simply:
- initializing the bond via ifconfig
- designating the slave interfaces via ifenslave
- adding the route for the bonded interface into kernel routing table manualy
However, if you want a bonded interface to be created during the boot/startup process--because rc.inet1 includes no functionality for bonded interfaces--you will need to either add the bond initialization commands into rc.local, or the better solution in my opinion, create another rc.d init script. (Note: this will require executable permissions, i.e. chmod 775.)
#!/bin/sh
# rc.bond
case "$1" in
'start')
echo "start bond0"
#modprobe bonding mode=balance-alb miimon=100
modprobe bonding mode=0 miimon=50
modprobe tg3
ifconfig bond0 up
ifconfig bond0 192.168.0.210 netmask 255.255.255.0
ifenslave bond0 eth0
ifenslave bond0 eth1
#TODO need to be changed
ifconfig bond0 hw ether 00:16:3e:aa:aa:aa
route add default gw 192.168.0.1 metric 1 bond0
;;
'stop')
ifconfig bond0 down
rmmod bonding
rmmod tg3
;;
*)
echo "Usage: $0 {start|stop}"
;;
esac
#EOF
Credit for the original rc.bond script goes to Mehdi Sadighian.
The bonds' IP & Netmask, and the gateway IP, will need to be changed to reflect your network.
My only modifications were adding the route command to add the default gw.
Also: make sure you modify the HW mac address if you intend to:
- make multiple bonds on the same system w/ this script
- utilize this rc.bond script on multiple systems in the same LAN (or VLAN).
When I first tested this out, I had just initialized a bonded interface on both of my servers in my lan, however I was stumped when my attempt to ssh into either system would time out. After digging I realized the HW mac address was the same for both systems in each LAN. Once I ensured each system had a unique MAC, ssh returned to normal and everything was right once again in the LAN.
Apparently, 00:16:3e:aa:aa:aa is the XenSource MAC prefix. Xen recommends its use because it will not conflict w/ any known hardware mac address. I feel this reason merits leaving the prefix here.
I've experimented w/ modifying rc.inet1.conf to include a bonding statement but... it doesn't quite work right. For one, that isn't the proper file to modify, since its sourced by rc.inet1 (which is the rc script that should be modified). 2, every time you run the rc.inet1 script--to start, stop, restart, doesn't matter--because rc.inet1 always sources rc.inet1.conf, it will call rc.bond regardless of the subcommand you pass to it. So when I shutdown my network the rc.bond script would initiate.
I suppose a work around would be to modify the case statement to only source rc.inet1.conf during network initialization.. this may be something to consider, still its really only a hack.
Honestly, even if the network stack stops, it isn't a problem if the rc.bond script initializes.. This can be seen as a good thing, you'll know none of the slave interfaces will accidentally be initialized w/ a ip address and route attached. (BTW--the documentation does list that as a known problem to watch for.)
However, as you've seen from my previous modifications to rc.inet1.conf, I've added sections for dns and hosts file settings, which now makes rc.inet1.conf more valuable to me. Valuable enough to not want initialize a bond w/o these settings being enabled.
So for now, if you want your system to startup w/ a bonded interface, the simplest solution is to create the rc.bond script I showed above, modify the bond to reflect your network (or add additional bonds), and finally add the following to rc.local:
/etc/rc.d/rc.bond start
In the slackbuild, I plan to include ifenslave tool, a sample rc.bond script to modify (like the one above), and a readme explaining the above.
In the future I will create a slackbuild that will actually utilize the sysfs interface instead, and thus be a supported method of bond creation, which will hopefully bring some cool features too.
Unfortunately, there isn't a current slackbuild in either's Slackware official package repo nor the slackbuilds repository which has a Slackbuild for ifenslave.
So, you're left building it from scratch as described in the source file ifenslave.c (/usr/src/linux/Documentation/networking/ifenslave.c):
compile-command: "gcc -Wall -Wstrict-prototypes -O -I/usr/src/linux/include ifenslave.c -o ifenslave"
When I was initially attempting to use the bonding driver, it was on my Poweredge 750 (arch: i686). For whatever reason, I could never get this source file to actually compile the binary ifenslave w/o encountering a build error.
This prompted me to look for an alternative. All the documentation I've seen in setting up bonding in Slackware walk you through this step first. In the major distros, ifenslave is either already included in the official repository, or bonding is integrated into the init script.
After some searching I finally came across an alternative: Vincent Batts posted a Slackbuild for ifenslave! It was hidden in the discarded directory, I believe it was for Slackware 12. It built just fine on my system!
(I later discovered what Vincent employed in his Slackbuild that actually allowed me to build ifenslave properly on my 14.1 x86 poweredge: the arch variable wasn't set via a case statement tied to uname--as is normally done-- it was hardcoded to 386.)
I was able to load the binary, initialize a bonded interface w/ ifconfig, and successfully utilized ifenslave to set the slave interfaces under the bond.
I've received Vincents permission to become the maintainer of the Slackbuild for the current release. I've modified it w/ enough core functionality to enable a Slackware installation to easily configure bonding. My difficulties in my journey to enable bonding in Slackware compelled me to create a solution that would bring this much needed functionality into Slackware into a simple installable package.
However, there is a caveat. Mainly, the current version of the Linux Bonding Driver (in the current stable kernel), no longer officially supports ifenslave--its use is now considered obsolete. This is sad, because the dev's reasoning is that a) most distro's include bonding functionality in the init scripts (a la RHEL), or b) in lack of such support you can always rely on creating a bond via the sysfs interface (/sys/class/net/bondX).
That being said, Slackware 14.1's kernel (3.10.17), still uses the older bonding driver, which supports ifenslave.
In fact--the current bonding driver doc mentions ifenslave will still function w/ the bonding driver and can be utilized. They just no longer support it and are in favor of the sysfs interface instead (which actually does provide more functionality in the bond initialization process).
So, I realize there is a need for this Slackbuild, although it will only be useful to a small audience (14.1). I'm not sure which kernel current is using, or if the bonding driver in that release still supports ifenslave or not.
Edit: I just checked kernel 3.14.29 (utilized at the moment in current); this kernel utilizes the updated bonding driver which does not officially support ifenslave.
To continue on though, ifenslave isn't the only thing we need to overcome in slackware. Sure, you could create a bond manually by simply:
- initializing the bond via ifconfig
- designating the slave interfaces via ifenslave
- adding the route for the bonded interface into kernel routing table manualy
However, if you want a bonded interface to be created during the boot/startup process--because rc.inet1 includes no functionality for bonded interfaces--you will need to either add the bond initialization commands into rc.local, or the better solution in my opinion, create another rc.d init script. (Note: this will require executable permissions, i.e. chmod 775.)
#!/bin/sh
# rc.bond
case "$1" in
'start')
echo "start bond0"
#modprobe bonding mode=balance-alb miimon=100
modprobe bonding mode=0 miimon=50
modprobe tg3
ifconfig bond0 up
ifconfig bond0 192.168.0.210 netmask 255.255.255.0
ifenslave bond0 eth0
ifenslave bond0 eth1
#TODO need to be changed
ifconfig bond0 hw ether 00:16:3e:aa:aa:aa
route add default gw 192.168.0.1 metric 1 bond0
;;
'stop')
ifconfig bond0 down
rmmod bonding
rmmod tg3
;;
*)
echo "Usage: $0 {start|stop}"
;;
esac
#EOF
Credit for the original rc.bond script goes to Mehdi Sadighian.
The bonds' IP & Netmask, and the gateway IP, will need to be changed to reflect your network.
My only modifications were adding the route command to add the default gw.
Also: make sure you modify the HW mac address if you intend to:
- make multiple bonds on the same system w/ this script
- utilize this rc.bond script on multiple systems in the same LAN (or VLAN).
When I first tested this out, I had just initialized a bonded interface on both of my servers in my lan, however I was stumped when my attempt to ssh into either system would time out. After digging I realized the HW mac address was the same for both systems in each LAN. Once I ensured each system had a unique MAC, ssh returned to normal and everything was right once again in the LAN.
Apparently, 00:16:3e:aa:aa:aa is the XenSource MAC prefix. Xen recommends its use because it will not conflict w/ any known hardware mac address. I feel this reason merits leaving the prefix here.
I've experimented w/ modifying rc.inet1.conf to include a bonding statement but... it doesn't quite work right. For one, that isn't the proper file to modify, since its sourced by rc.inet1 (which is the rc script that should be modified). 2, every time you run the rc.inet1 script--to start, stop, restart, doesn't matter--because rc.inet1 always sources rc.inet1.conf, it will call rc.bond regardless of the subcommand you pass to it. So when I shutdown my network the rc.bond script would initiate.
I suppose a work around would be to modify the case statement to only source rc.inet1.conf during network initialization.. this may be something to consider, still its really only a hack.
Honestly, even if the network stack stops, it isn't a problem if the rc.bond script initializes.. This can be seen as a good thing, you'll know none of the slave interfaces will accidentally be initialized w/ a ip address and route attached. (BTW--the documentation does list that as a known problem to watch for.)
However, as you've seen from my previous modifications to rc.inet1.conf, I've added sections for dns and hosts file settings, which now makes rc.inet1.conf more valuable to me. Valuable enough to not want initialize a bond w/o these settings being enabled.
So for now, if you want your system to startup w/ a bonded interface, the simplest solution is to create the rc.bond script I showed above, modify the bond to reflect your network (or add additional bonds), and finally add the following to rc.local:
/etc/rc.d/rc.bond start
In the slackbuild, I plan to include ifenslave tool, a sample rc.bond script to modify (like the one above), and a readme explaining the above.
In the future I will create a slackbuild that will actually utilize the sysfs interface instead, and thus be a supported method of bond creation, which will hopefully bring some cool features too.
Linux Bonding Channel Driver, on Slackware P2
So, I've been trying to get this to work for.. shit since October 2014, no success until now.
First, I tried bonding interfaces w/ my unmanaged HP Procurve2724 16 port gigabit switch. No Luck.
I figured I should look into a managed switch, hopefully LACP functionality will be present.
So I headed to my favourite place (Westech Recyclers--Resell Electronics), and picked up a D-Link DGS-1248T for a whopping 10 buckaroos. (Apparently a steal, this thing retailed for 300-600 new, holy cow.)
So I had a made a big misunderstanding in my research: the "trunking functionality" being described in the Linux Bonding Driver documentation as , well, compatible w/ 802.3ad!
What I didn't realize in my eagerness, I looked at the modes and chose 802.3ad (mode=4), as the one I wanted to use.
What I didn't realize, 802.3ad--which utilizes LACP--is a IEEE draft specification completely different than trunking.
In fact, I didn't know what Trunking really meant. I knew it was described in the Bonding Driver documentation, and that it was supported by my switch (DGS 1248T). When I reffered to the switches documentation, it wasn't descriptive in the least bit:
"The Trunk function enables the Switch to cascade two or more devices with larger bandwidths."
Devices? You Mean ports? Or Devices as in switches? Is this meant to trunk switches or ports? I was royally confused.
So here I was, spinning my wheels, for weeks, trying to get mode=4 w/ the DGS-1248T. I wasn't using VLANs, I simply enabled two groups of ports: one for my main system, and one for my other storage server.
Whenever I enabled the bond, I added the default gw route on the bond, but it would never reach the gateway. The command would time out. Actually it did work twice, but it would not work after reboots nor after disableing and re-enabling the bonded interface.
I was stumped. What is going on?
Finally, after reading a post on LQ forums regarding another users experience w/ this switch and bonded interfaces--specifically, his bonds were working! I thought--no way, how?
He wasn't using mode=4. He was using mode=2 (Balance-xor).
I decided to try it. In my system, I decided to use mode=0--Balance-rr. I was now able to add the default gw route on the bond! And I could communicate to the lan and internet!
I determined that the bond was initalized correctly and functioning on both of my servers (HP G5 ML350, and a poweredge 1850). Both bonded interfaces could send and recive on the lan and internet.
I still didn't understand why. It wasn't until I was looking at the Bonding Driver documentation this evening, that I realized why:
Requirements for specific modes:
... The Switch must be configured for "etherchannel," or "trunking," on the appropriate ports.
As I later discovered, etherchannel is Cisco's proprietary implementation of link aggregation which predated the 802.3ad spec. Furthermore, because etherchannel is cisco proprietary technology, the trunking variants seen in other mfg's switches must be that manufacturers implementation/etherchannel variant.
In other words, the only things they really lose is support for ISL and VTP, both Cisco proprietary technologies anyways.
The main reason I went through all this trouble was to determine first hand whether there was any measurable speed increase in using bonding.
I made a simple test, basically I transfered a large file over a single gigabit (via mounted nfs directory and using a simple copy).
As I've read--and discovered in my own experience--although the theoritical maximum transfer rate for a gigabit interface is 125MB/s, the real transfer rate is much slower. The reasons vary considerably, but generally mechanical drives are the main cause of the bottleneck (followed by system load or network traffic). In other tests that I've seen test a true gigabit transfer rate on a system, they utilized a ramdrive. So, for this test I created a 2 GB ramdisk via the newer tmpfs. I then copied the large file (1.5GB mp4), over the NFS mounted locally (hosted of second server also using bonded interface), to the mounted ramdisk filesystem (mounted as tmpfs and using tmpfs filesystem).
I then reran the same test, using the bonded interface w/ mode=2 (balance-rr).
The results did not dissapoint!
Transferred 1.5GB mp4 file over locally mounted nfs (hosted on secondary server), to tmpfs mounted filesystem:
1GB NIC Transfer: 50 MB/s
Bond0 (dual 1G NIC slaves): 94 MB/s
The bond transferred nearly twice as fast!
First, I tried bonding interfaces w/ my unmanaged HP Procurve2724 16 port gigabit switch. No Luck.
I figured I should look into a managed switch, hopefully LACP functionality will be present.
So I headed to my favourite place (Westech Recyclers--Resell Electronics), and picked up a D-Link DGS-1248T for a whopping 10 buckaroos. (Apparently a steal, this thing retailed for 300-600 new, holy cow.)
So I had a made a big misunderstanding in my research: the "trunking functionality" being described in the Linux Bonding Driver documentation as , well, compatible w/ 802.3ad!
What I didn't realize in my eagerness, I looked at the modes and chose 802.3ad (mode=4), as the one I wanted to use.
What I didn't realize, 802.3ad--which utilizes LACP--is a IEEE draft specification completely different than trunking.
In fact, I didn't know what Trunking really meant. I knew it was described in the Bonding Driver documentation, and that it was supported by my switch (DGS 1248T). When I reffered to the switches documentation, it wasn't descriptive in the least bit:
"The Trunk function enables the Switch to cascade two or more devices with larger bandwidths."
Devices? You Mean ports? Or Devices as in switches? Is this meant to trunk switches or ports? I was royally confused.
So here I was, spinning my wheels, for weeks, trying to get mode=4 w/ the DGS-1248T. I wasn't using VLANs, I simply enabled two groups of ports: one for my main system, and one for my other storage server.
Whenever I enabled the bond, I added the default gw route on the bond, but it would never reach the gateway. The command would time out. Actually it did work twice, but it would not work after reboots nor after disableing and re-enabling the bonded interface.
I was stumped. What is going on?
Finally, after reading a post on LQ forums regarding another users experience w/ this switch and bonded interfaces--specifically, his bonds were working! I thought--no way, how?
He wasn't using mode=4. He was using mode=2 (Balance-xor).
I decided to try it. In my system, I decided to use mode=0--Balance-rr. I was now able to add the default gw route on the bond! And I could communicate to the lan and internet!
I determined that the bond was initalized correctly and functioning on both of my servers (HP G5 ML350, and a poweredge 1850). Both bonded interfaces could send and recive on the lan and internet.
I still didn't understand why. It wasn't until I was looking at the Bonding Driver documentation this evening, that I realized why:
Requirements for specific modes:
... The Switch must be configured for "etherchannel," or "trunking," on the appropriate ports.
As I later discovered, etherchannel is Cisco's proprietary implementation of link aggregation which predated the 802.3ad spec. Furthermore, because etherchannel is cisco proprietary technology, the trunking variants seen in other mfg's switches must be that manufacturers implementation/etherchannel variant.
In other words, the only things they really lose is support for ISL and VTP, both Cisco proprietary technologies anyways.
The main reason I went through all this trouble was to determine first hand whether there was any measurable speed increase in using bonding.
I made a simple test, basically I transfered a large file over a single gigabit (via mounted nfs directory and using a simple copy).
As I've read--and discovered in my own experience--although the theoritical maximum transfer rate for a gigabit interface is 125MB/s, the real transfer rate is much slower. The reasons vary considerably, but generally mechanical drives are the main cause of the bottleneck (followed by system load or network traffic). In other tests that I've seen test a true gigabit transfer rate on a system, they utilized a ramdrive. So, for this test I created a 2 GB ramdisk via the newer tmpfs. I then copied the large file (1.5GB mp4), over the NFS mounted locally (hosted of second server also using bonded interface), to the mounted ramdisk filesystem (mounted as tmpfs and using tmpfs filesystem).
I then reran the same test, using the bonded interface w/ mode=2 (balance-rr).
The results did not dissapoint!
Transferred 1.5GB mp4 file over locally mounted nfs (hosted on secondary server), to tmpfs mounted filesystem:
1GB NIC Transfer: 50 MB/s
Bond0 (dual 1G NIC slaves): 94 MB/s
The bond transferred nearly twice as fast!
Linux Ethernet Bonding Driver, on Slackware P1
I've been wanting to utilize the Linux Ethernet Bonding Driver in my lab since I got my hands on a few managed switches that would support trunking. However, although I've bonded fiberchannel HBA network interfaces for our clients servers when I was a Linux Admin (all of the systems in the Phoenix AZ co-location were internetworked using 8g Fiberchannel interfaces. (Storage array's utilized 16G FC, as well as the core infrastructure switches which the clients environments were hosted on.)
However, this was mostly on RHEL 6 systems, some SLES, one (or two Ubuntu servers), and Oracle Enterprise Linux--Oracle's RHEL clone which now goes by Oracle Linux (probably to avoid confusion).
I have to say the majority of the systems I managed w/ RHEL, w/ Oracle Linux coming second. Most of the Oracle Linux systems were actually full blown virtualization servers, utilizing Oracle's proprietary virtualization platform--Oracle VM Server. (Unlike the opensource VirtualBox, VM Server is Oracle's customized version of Xen. In fact all of the Oracle Linux systems were running VM Server to host the clients systems.
Anyways, enough reminiscing. That didn't really help in my current endeavor. Although RHEL has functionality in the /etc/sysconfig/network file to recognize and initiate bonded interfaces, Slackware is not quite there.
In fact according to my findings, there is no built in functionality at all in the network init script--/etc/rc.d/rc.inet1.
So, taking a look at /etc/rc.d/rc.inet1, we can figure out what is going on when the network is initialized. Basically, the author created a few main functions: read network config file (rc.inet1.conf), create logs in system logfile (/var/log/messages), determine interface list (while loop w/ incremental array variable to differentiate between eth0 or eth1), loopback functions (initialize loopback interface), interface functions (the real enchilada of the script--br_open, br_close, if_up, and if_down), gateway function (route command initializes gateway defined in rc.inet1.conf), and finally the main function (case statement which defines the network scripts subcommands: start, restart, up, down, etc...
So, we have to look into the interface functions, specifically if_up. We really don't have to look at the whole thing line by line, simply skimming it will reveal that there is no functionality inherent in this script to initialize a bonded interface as is done in RHEL.
If Slackware is going to really be considered a Server OS, we need to modify this as soon as possible. I've hacked up my own work around, but am not confident in modifying the rc.inet1 network script enough that it will be fullproof (error free, or prone to wacky behavior). I'm willing to try (believe me I've started), but I feel this issue needs to be evaluated by Slackware team (Pat, Rob, Eric, Sudayo, I hope someones reading this.) This could easily be solved by adding function specifically for initializing a bonded interface in the interface functions, and even more important, that rc.inet1.conf can recognize a bonded interface and pass those variables to the main enchilada (rc.inet1).
I've been tried adding my own functions, but I keep overlooking some important steps.. mainly, how to differentiate between whether the script defines a bridge interface (must be created first), or a bonded interface, or if it wishes to bridge a set of bonded interfaces, or if there are no bridges and only bonds are used, to initialize those first while ensuring the slave interfaces are left disabled.
I've considered looking at redhats network init script for ideas, but as I've confessed, I am not confident any modifications I create would work properly.
I really hope the Slackware team considers this suggestion, and realize that it would benefit a large target audience--servers specifically--and aid in Slackware's adoption as a server OS. Especially w/ the RHEL crowd.
____
To be continued...
However, this was mostly on RHEL 6 systems, some SLES, one (or two Ubuntu servers), and Oracle Enterprise Linux--Oracle's RHEL clone which now goes by Oracle Linux (probably to avoid confusion).
I have to say the majority of the systems I managed w/ RHEL, w/ Oracle Linux coming second. Most of the Oracle Linux systems were actually full blown virtualization servers, utilizing Oracle's proprietary virtualization platform--Oracle VM Server. (Unlike the opensource VirtualBox, VM Server is Oracle's customized version of Xen. In fact all of the Oracle Linux systems were running VM Server to host the clients systems.
Anyways, enough reminiscing. That didn't really help in my current endeavor. Although RHEL has functionality in the /etc/sysconfig/network file to recognize and initiate bonded interfaces, Slackware is not quite there.
In fact according to my findings, there is no built in functionality at all in the network init script--/etc/rc.d/rc.inet1.
So, taking a look at /etc/rc.d/rc.inet1, we can figure out what is going on when the network is initialized. Basically, the author created a few main functions: read network config file (rc.inet1.conf), create logs in system logfile (/var/log/messages), determine interface list (while loop w/ incremental array variable to differentiate between eth0 or eth1), loopback functions (initialize loopback interface), interface functions (the real enchilada of the script--br_open, br_close, if_up, and if_down), gateway function (route command initializes gateway defined in rc.inet1.conf), and finally the main function (case statement which defines the network scripts subcommands: start, restart, up, down, etc...
So, we have to look into the interface functions, specifically if_up. We really don't have to look at the whole thing line by line, simply skimming it will reveal that there is no functionality inherent in this script to initialize a bonded interface as is done in RHEL.
If Slackware is going to really be considered a Server OS, we need to modify this as soon as possible. I've hacked up my own work around, but am not confident in modifying the rc.inet1 network script enough that it will be fullproof (error free, or prone to wacky behavior). I'm willing to try (believe me I've started), but I feel this issue needs to be evaluated by Slackware team (Pat, Rob, Eric, Sudayo, I hope someones reading this.) This could easily be solved by adding function specifically for initializing a bonded interface in the interface functions, and even more important, that rc.inet1.conf can recognize a bonded interface and pass those variables to the main enchilada (rc.inet1).
I've been tried adding my own functions, but I keep overlooking some important steps.. mainly, how to differentiate between whether the script defines a bridge interface (must be created first), or a bonded interface, or if it wishes to bridge a set of bonded interfaces, or if there are no bridges and only bonds are used, to initialize those first while ensuring the slave interfaces are left disabled.
I've considered looking at redhats network init script for ideas, but as I've confessed, I am not confident any modifications I create would work properly.
I really hope the Slackware team considers this suggestion, and realize that it would benefit a large target audience--servers specifically--and aid in Slackware's adoption as a server OS. Especially w/ the RHEL crowd.
____
To be continued...
Wednesday, January 21, 2015
modifications to /etc/rc.d/rc.inet1.conf
Hey everyone, just thought I'd share my modifications to /etc/rc.d/rc.inet1.conf. These are pretty simple, but very effective in my opionion.
Basically, I really had to learn the hard way the importance of /etc/resolv.conf, and how to set a hostname. I really don't like how you have to hunt in order to get these settings in place. In my opinion, editing a textfile by hand is fine, but doing it all in one place is simpler than going to different files.
Then again, people may view this as an abomination, and respond by saying things should be kept the old way. Take a look and let me know what you think :)
# /etc/rc.d/rc.inet1.conf
.
.
.
# Set hostname
# This will set your hostname as defined in /etc/hosts.
# This only works if you have a properly defined /etc/hosts file.
# In order for these settings to take effect, after properly modifying
# /etc/hosts, you must restart network (/etc/rc.d/rc.inet1 restart),
# exit your current shell, and log back in--or log in to a new shell.
# Please refer to man /etc/hosts for more information.
hsts=$(cat /etc/hosts | grep 127.0.0.1 | egrep -v 'localhost|Arnt' | cut -f 2)
if [ -n $hsts ]; then
HOSTNAME=$hsts
hst=$(echo $hsts | sed 's/\..*//')
echo $hsts > /etc/HOSTNAME
echo $hst > /etc/HOSTNAME_S
hostname -F /etc/HOSTNAME_S
fi
# Config information for eth0:
.
.
# Default gateway IP address:
GATEWAY=""
# DNS Settings
# Either run dhcpd once to create a temp /etc/resolv.conf and copy values
# below, or get the values from your ISP / Router / Modem.
# Uncomment nameservers as necessary for your network.
domain=ph.cox.net
nameserver1=192.168.0.1
#nameserver2=68.105.28.11
#nameserver3=68.105.29.11
# Create resolv.conf
# Uncomment nameservers as necessary for your network.
if [ -x /etc/resolv.conf ]; then
echo "" > /etc/resolv.conf
else
touch /etc/resolv.conf
echo "domain $domain" > /etc/resolv.conf
echo "nameserver $nameserver1" >> /etc/resolv.conf
#echo "nameserver $nameserver2" >> /etc/resolv.conf
#echo "nameserver $nameserver3" >> /etc/resolv.conf
fi
So basically, to summarize, skip the comments and the ethernet section (those are still there but you know what it looks like). The parts I added was the hostname section, the DNS settings, and creating resolv.conf. These easily make resolv.conf for you when rc.inet1 is being run--in other words when network is being brought up. The hostname according to the hostname manpage is supposedly also setup when rc.inet1 is ran, but it doesn't accept changes to /etc/hosts on the fly. I didn't like this, which is why I modified rc.inet1.conf as such.
This script requires you to have a properly modified /etc/hosts, like such:
# For loopbacking.
127.0.0.1 localhost
# This next entry is technically wrong, but good enough to get TCP/IP apps
# to quit complaining that they can't verify the hostname on a loopback-only
# Linux box.
127.0.0.1 bpm37093.centauri.net bpm37093
192.168.0.200 beta.centauri.net beta
192.168.0.210 v766.centauri.net v766
192.168.0.220 bpm37093.centauri.net bpm37093
The nice thing about adding this section is that, you can have your hostname update on the fly, all you have to do is restart the network (/etc/rc.d/rc.inet1 restart), and then make sure to exit and log back in to your shell/ log in to a new shell. And viola! Your hostname will now show up :)
The DNS settings, well ... the easiest way to get those is to either run dhcpd once--which will auto generate a resolv.conf for you. Once you have those settings you can populate the DNS settings sections with what is suitable for your network.
Alternatively you don't have to run dhcpd. You can just get the settings from your router, or modem, and go from there.
Also, you may not need as many nameservers. Simply uncomment the appropriate nameserver variables/ echo statements as neccessary for your network. Also, you can add additional nameservers, you just have to add another nameserver line in the dns section and an extra echo statement in the resolv.conf section. However 3 is more than enough (2 is generally what most ISP's use, the 3rd is for your router if it supports it).
Below are links to the modified /etc/rc.d/rc.inet1.conf file and an accompanying md5 file (so you can sure what youre downloading isn't some bullshit garbage:b).
- rc.inet1.conf - modified: http://www.datafilehost.com/d/57b5c9f0
- rc.inet1.conf - md5sum: http://www.datafilehost.com/d/86fc1021
Basically, I really had to learn the hard way the importance of /etc/resolv.conf, and how to set a hostname. I really don't like how you have to hunt in order to get these settings in place. In my opinion, editing a textfile by hand is fine, but doing it all in one place is simpler than going to different files.
Then again, people may view this as an abomination, and respond by saying things should be kept the old way. Take a look and let me know what you think :)
# /etc/rc.d/rc.inet1.conf
.
.
.
# Set hostname
# This will set your hostname as defined in /etc/hosts.
# This only works if you have a properly defined /etc/hosts file.
# In order for these settings to take effect, after properly modifying
# /etc/hosts, you must restart network (/etc/rc.d/rc.inet1 restart),
# exit your current shell, and log back in--or log in to a new shell.
# Please refer to man /etc/hosts for more information.
hsts=$(cat /etc/hosts | grep 127.0.0.1 | egrep -v 'localhost|Arnt' | cut -f 2)
if [ -n $hsts ]; then
HOSTNAME=$hsts
hst=$(echo $hsts | sed 's/\..*//')
echo $hsts > /etc/HOSTNAME
echo $hst > /etc/HOSTNAME_S
hostname -F /etc/HOSTNAME_S
fi
# Config information for eth0:
.
.
# Default gateway IP address:
GATEWAY=""
# DNS Settings
# Either run dhcpd once to create a temp /etc/resolv.conf and copy values
# below, or get the values from your ISP / Router / Modem.
# Uncomment nameservers as necessary for your network.
domain=ph.cox.net
nameserver1=192.168.0.1
#nameserver2=68.105.28.11
#nameserver3=68.105.29.11
# Create resolv.conf
# Uncomment nameservers as necessary for your network.
if [ -x /etc/resolv.conf ]; then
echo "" > /etc/resolv.conf
else
touch /etc/resolv.conf
echo "domain $domain" > /etc/resolv.conf
echo "nameserver $nameserver1" >> /etc/resolv.conf
#echo "nameserver $nameserver2" >> /etc/resolv.conf
#echo "nameserver $nameserver3" >> /etc/resolv.conf
fi
So basically, to summarize, skip the comments and the ethernet section (those are still there but you know what it looks like). The parts I added was the hostname section, the DNS settings, and creating resolv.conf. These easily make resolv.conf for you when rc.inet1 is being run--in other words when network is being brought up. The hostname according to the hostname manpage is supposedly also setup when rc.inet1 is ran, but it doesn't accept changes to /etc/hosts on the fly. I didn't like this, which is why I modified rc.inet1.conf as such.
This script requires you to have a properly modified /etc/hosts, like such:
# For loopbacking.
127.0.0.1 localhost
# This next entry is technically wrong, but good enough to get TCP/IP apps
# to quit complaining that they can't verify the hostname on a loopback-only
# Linux box.
127.0.0.1 bpm37093.centauri.net bpm37093
192.168.0.200 beta.centauri.net beta
192.168.0.210 v766.centauri.net v766
192.168.0.220 bpm37093.centauri.net bpm37093
The nice thing about adding this section is that, you can have your hostname update on the fly, all you have to do is restart the network (/etc/rc.d/rc.inet1 restart), and then make sure to exit and log back in to your shell/ log in to a new shell. And viola! Your hostname will now show up :)
The DNS settings, well ... the easiest way to get those is to either run dhcpd once--which will auto generate a resolv.conf for you. Once you have those settings you can populate the DNS settings sections with what is suitable for your network.
Alternatively you don't have to run dhcpd. You can just get the settings from your router, or modem, and go from there.
Also, you may not need as many nameservers. Simply uncomment the appropriate nameserver variables/ echo statements as neccessary for your network. Also, you can add additional nameservers, you just have to add another nameserver line in the dns section and an extra echo statement in the resolv.conf section. However 3 is more than enough (2 is generally what most ISP's use, the 3rd is for your router if it supports it).
Below are links to the modified /etc/rc.d/rc.inet1.conf file and an accompanying md5 file (so you can sure what youre downloading isn't some bullshit garbage:b).
- rc.inet1.conf - modified: http://www.datafilehost.com/d/57b5c9f0
- rc.inet1.conf - md5sum: http://www.datafilehost.com/d/86fc1021
Saturday, January 17, 2015
Mozilla Firefox 35: Profile Guided Optimization
While inspecting the Firefox SlackBuild, I noticed it had an elif statement dedicated to PGO (Profile Guided Optimization):
if [ "$ARCH" = "x86_64" ]; then
PGO=${PGO:-yes}
else
PGO=${PGO:-no}
fi
This feature is mentioned in the SlackBuild bundled w/ the 24.1.0 extended support release (i.e. the stock 14.1 package). I decided to investigate and see what this fuss is about.
From Mozilla's FAQ:
"The Mozilla build system contains support for building with Profile-Guided Optimization (PGO) with GCC 4 or newer and Microsoft Visual C++ 2005 (Professional Edition) or newer. A PGO build consists of two passes: a first pass to build instrumented binaries, then a second pass to re-build optimized binaries using profile information gleaned from running the instrumented binaries. The Mozilla build system will run both passes for you, as well as a profile generation script in between."
From Wikipedia's page on PGO:
"Optimization techniques based on analysis of the source code alone are based on general ideas as to possible improvements, often applied without much worry over whether or not the code section was going to be executed frequently though also recognizing that code within looping statements is worth extra attention.
The first high-level compiler, introduced as the FORTRAN Automatic Coding System in 1957, broke the code into blocks and devised a table of the frequency each block is executed via a simulated execution of the code in a Monte Carlo fashion in which the outcome of conditional transfers (as via IF-type statements) is determined by a random number generator suitably weighted by whatever FREQUENCY statements were provided by the programmer. [3]
Rather than programmer-supplied frequency information, profile-guided optimization uses the results of profiling test runs of the instrumented program to optimize the final generated code.[4][5] The compiler is used to access data from a sample run of the program across a representative input set. The results indicate which areas of the program are executed more frequently, and which areas are executed less frequently. All optimizations benefit from profile-guided feedback because they are less reliant on heuristics when making compilation decisions. The caveat, however, is that the sample of data fed to the program during the profiling stage must be statistically representative of the typical usage scenarios; otherwise, profile-guided feedback has the potential to harm the overall performance of the final build instead of improving it."
I decided to compile Mozilla Firefox 35 w/ PGO enabled. It took approximately 4 solid hours to compile along with 8GB of disk space.
I decided to run some tests of my own to determine the validity of this optimization hype. A quick Google search for the term "browser benchmark," led me to futuremark's peacekeeper browser benchmark:
http://peacekeeper.futuremark.com/
Peacekeeper tests a variety of operations, including:
> Rendering: manipulate DOM tree in real-time.
> HTML5 - WebGL: MJS Matrix/Vector package.
> HTML5 - Video: tests supported video formats.
> HTML5 - Web Worker: tests javascripts multithreading.
> HTML5 - Game: 2D sprite game (modified version of Crafty). Sprites increase as test progresses to increase load.
> Canvas: HTML5 Canvas.
> Data test suite:
> DOM operations: the Document Object Model Javascript API.
> Text Parsing:
(A detailed explanation of the tests ran in the benchmark suite can be found at the following link.)
The results were very revealing!
- Mozilla-Firefox-35.x86_64: 3521 Points
- Mozilla-Firefox-35.x86_64.pgo-enabled: 3724 Points
(The above links provide the detailed results for each package.)
That settles the argument: Firefox compiled w/ profile guided optimization has a measurable performance gain.
I am currently using the pgo-enabled Firefox build and will continue to do so unless it: creates a security risk, introduces regressions, or breaks future builds.
I have provided a PGO-enabled Firefox package for those of you who want to try it out and don't want to invest the time (and disk space), to compile:
-> mozilla-firefox-35.0.pgo-x86_64-1.txz
-> mozilla-firefox-35.0.pgo-x86_64-1.md5
I encourage you guys to try out the PGO-enabled build on your systems and run through the peacekeeper benchmark! I'm very curious to see any differences in performance! Also, I know I haven't provided a x86 (32bit), build yet, that will follow soon for both the vanilla firefox-35 and the PGO-enabled build!
*Also, I am asking my readers a huge favor: if anyone has an ftp, a repository, or server where I can upload these packages, I would greatly appreciate any input! These packages deserve a proper home!*
Diego
if [ "$ARCH" = "x86_64" ]; then
PGO=${PGO:-yes}
else
PGO=${PGO:-no}
fi
This feature is mentioned in the SlackBuild bundled w/ the 24.1.0 extended support release (i.e. the stock 14.1 package). I decided to investigate and see what this fuss is about.
From Mozilla's FAQ:
"The Mozilla build system contains support for building with Profile-Guided Optimization (PGO) with GCC 4 or newer and Microsoft Visual C++ 2005 (Professional Edition) or newer. A PGO build consists of two passes: a first pass to build instrumented binaries, then a second pass to re-build optimized binaries using profile information gleaned from running the instrumented binaries. The Mozilla build system will run both passes for you, as well as a profile generation script in between."
From Wikipedia's page on PGO:
"Optimization techniques based on analysis of the source code alone are based on general ideas as to possible improvements, often applied without much worry over whether or not the code section was going to be executed frequently though also recognizing that code within looping statements is worth extra attention.
The first high-level compiler, introduced as the FORTRAN Automatic Coding System in 1957, broke the code into blocks and devised a table of the frequency each block is executed via a simulated execution of the code in a Monte Carlo fashion in which the outcome of conditional transfers (as via IF-type statements) is determined by a random number generator suitably weighted by whatever FREQUENCY statements were provided by the programmer. [3]
Rather than programmer-supplied frequency information, profile-guided optimization uses the results of profiling test runs of the instrumented program to optimize the final generated code.[4][5] The compiler is used to access data from a sample run of the program across a representative input set. The results indicate which areas of the program are executed more frequently, and which areas are executed less frequently. All optimizations benefit from profile-guided feedback because they are less reliant on heuristics when making compilation decisions. The caveat, however, is that the sample of data fed to the program during the profiling stage must be statistically representative of the typical usage scenarios; otherwise, profile-guided feedback has the potential to harm the overall performance of the final build instead of improving it."
I decided to compile Mozilla Firefox 35 w/ PGO enabled. It took approximately 4 solid hours to compile along with 8GB of disk space.
I decided to run some tests of my own to determine the validity of this optimization hype. A quick Google search for the term "browser benchmark," led me to futuremark's peacekeeper browser benchmark:
http://peacekeeper.futuremark.com/
Peacekeeper tests a variety of operations, including:
> Rendering: manipulate DOM tree in real-time.
> HTML5 - WebGL: MJS Matrix/Vector package.
> HTML5 - Video: tests supported video formats.
> HTML5 - Web Worker: tests javascripts multithreading.
> HTML5 - Game: 2D sprite game (modified version of Crafty). Sprites increase as test progresses to increase load.
> Canvas: HTML5 Canvas.
> Data test suite:
> DOM operations: the Document Object Model Javascript API.
> Text Parsing:
(A detailed explanation of the tests ran in the benchmark suite can be found at the following link.)
The results were very revealing!
- Mozilla-Firefox-35.x86_64: 3521 Points
- Mozilla-Firefox-35.x86_64.pgo-enabled: 3724 Points
(The above links provide the detailed results for each package.)
That settles the argument: Firefox compiled w/ profile guided optimization has a measurable performance gain.
I am currently using the pgo-enabled Firefox build and will continue to do so unless it: creates a security risk, introduces regressions, or breaks future builds.
I have provided a PGO-enabled Firefox package for those of you who want to try it out and don't want to invest the time (and disk space), to compile:
-> mozilla-firefox-35.0.pgo-x86_64-1.txz
-> mozilla-firefox-35.0.pgo-x86_64-1.md5
I encourage you guys to try out the PGO-enabled build on your systems and run through the peacekeeper benchmark! I'm very curious to see any differences in performance! Also, I know I haven't provided a x86 (32bit), build yet, that will follow soon for both the vanilla firefox-35 and the PGO-enabled build!
*Also, I am asking my readers a huge favor: if anyone has an ftp, a repository, or server where I can upload these packages, I would greatly appreciate any input! These packages deserve a proper home!*
Diego
Friday, January 16, 2015
Mozilla Firefox 35
Mozilla is currently on version 35 of firefox, and slackware current is on 34. I was aghast when I realized that I was still using version 24, and even more so when I realized that 14.1 had officially upgraded to 31 (extended support release).
I compiled version 34 and installed it in my system (14.1 x86_64), and then decided to try out 35. I grabbed the source from mozilla's ftp and built it against the slackbuild provided in current for version 34.
So far it works great! No issues whatsoever. I am currently re-compiling w/ pgo support enabled. Although pgo was enabled in the slackbuild by default in version 24 (stock 14.1 release), it has since been disabled in current. As mentioned in the comments it has definetely more than doubled the compile time, but I'm sticking it out to see if there is any performance enhancement with pgo enabled.
Below is a link I've provided for the lazy who wish to try out the latest (& greatest), Mozilla Firefox release 35 on there systems (and don't want to wait the hour or 2 to compile)!:
mozilla-firefox-35.0-x86_64-1.txz:
- http://www.datafilehost.com/d/3ebe4440
mozilla-firefox-35.0-x86_64-1.md5:
- http://www.datafilehost.com/d/2bd93007
I will build an x86 for on my poweredge later this evening. Stay tuned!
I compiled version 34 and installed it in my system (14.1 x86_64), and then decided to try out 35. I grabbed the source from mozilla's ftp and built it against the slackbuild provided in current for version 34.
So far it works great! No issues whatsoever. I am currently re-compiling w/ pgo support enabled. Although pgo was enabled in the slackbuild by default in version 24 (stock 14.1 release), it has since been disabled in current. As mentioned in the comments it has definetely more than doubled the compile time, but I'm sticking it out to see if there is any performance enhancement with pgo enabled.
Below is a link I've provided for the lazy who wish to try out the latest (& greatest), Mozilla Firefox release 35 on there systems (and don't want to wait the hour or 2 to compile)!:
mozilla-firefox-35.0-x86_64-1.txz:
- http://www.datafilehost.com/d/3ebe4440
mozilla-firefox-35.0-x86_64-1.md5:
- http://www.datafilehost.com/d/2bd93007
I will build an x86 for on my poweredge later this evening. Stay tuned!
Subscribe to:
Posts (Atom)