Hello all,
I am pleased to announce the immediate availability of nightly builds of the OpenShift Origin package set in RPM form, built for Fedora 16 available to anyone who might be interested in them here.
This repository should be utilized along with the instructions outlined in the "Build your own PaaS" article. The nightly repository will not take the place of any of those outlined in the guide but will instead supplement what is there and offer a new development snapshot of all the packages who's source code originates in the OpenShift Origin github repositories.
A little back story on this, the OpenShift Team at Red Hat has been looking for more ways to provide the community with as many opportunities to consume the on going development snapshots of the upstream code hosted on github. We initially launched OpenShift Origin's components Crankcase and OS-Client tools on github which is something I've been extremely excited about and along with that launch was a considerable amount of documentation for getting started and involved with OpenShift Origin which I would highly encourage everyone take some time to go check out, it's certainly exciting stuff!
Now, with the advent of the nightly rpm builds my hope is that this will be the first of many steps towards the goal of delivering the code in a more consumable manner so that end users who are wanting to get their hands dirty early on are able to do so without having to build everything from scratch. Another desire as a side effect of this is that those community members who do consume the nightly builds will find the project as exciting as those of us already involved and will hopefully be motived to join and contribute! I'm also hoping that we will be able to get to a point where we can also offer nightly builds of the OpenShift Origin LiveCD, that Krishna Raman has been doing great work on, but that is currently just an idea I've been pondering and I don't want to make any promises I am unable to deliver on. We'd like to make sure everyone does know we're continuing to brainstorm ideas, take suggestions and contributions, and make strides to continue our open source commitment to the community.
I suppose that's all for today, thanks to everyone who's been using OpenShift and becoming members of the OpenShift Origin community!
Happy hacking,
-AdamM
Tuesday, May 22, 2012
Wednesday, March 28, 2012
NetworkManager is in @core but don't fret ....
Recently there was a not so announced change to Fedora's @core and that is that NetworkManager is now a part of it. This initially will cause the traditional *nix admins to have a moment of "WTF?" but bear with me as I also had this reaction but I've slept on it and it clearly has yet to kill me. Lets address a couple things in a light hearted nature of the angry mob that is the internet:
ifcfg-rh
plugin is used on the Fedora and Red Hat Enterprise Linux distribu-
tions to read and write configuration from the standard /etc/syscon-
fig/network-scripts/ifcfg-* files. It currently supports reading
wired, WiFi, and 802.1x connections, but does not yet support read-
ing or writing mobile broadband, PPPoE, or VPN connections. To allow
reading and writing of these add keyfile plugin to your configura-
tion as well.
NM_CONTROLLED=yes|no
If set to 'no', NetworkManager will ignore this connection/device.
Defaults to 'yes'.
What does this mean? Well ... if you did a fresh install, chances are your interfaces already have this but if you've got a machine that's been upgrading through the timeline to this point, if you just add that little line and fire up NetworkManager it will apply your settings for you. Magic! I know, pretty cool huh? :)
_____________________________ <--- the line where joking stops
In all seriousness, this is a change that is bound to ruffle some feathers but the reality is that with the pace in which Fedora moves it is sometimes best to take the path of least resistance in order to solve a problem and I think that's what's been done here. If there are any real concerns (I mean really valid concerns and not just "I hate change") then I like to believe that the greater community would be willing to entertain them in the proper channels of communication and if necessary then decisions made to fix issues can be altered/modified as needed to suite the needs of the project. I think we as faithful members of the community like to knee jerk react a little too much and I'm 100% guilty of this myself, but I think if we spend some time actually processing the scenarios, possible outcomes and attempt to include as many factors as possible we can see that inclusions of things like NetworkManager into @core aren't there just to add some packages for kicks but that there's actual valid reason. Fedora doesn't change for the sake of change, its changing to make a better project and platform for all to enjoy, and in this case its about squashing bugs so our experience is more pleasant other times it about innovation.... in the end, horray for another closed bug! :)
Happy hacking,
-AdamM
WHY?!?!!@#^@!$#!@#$!%^ZOMG!#@!!11!1!$eleventyone!!?@!?@
Well the motivation was simple, there was a bug and it was nasty and decisions needed making. One was made and at first you might not be on board with it, or you might never, but at face value its not really that bad since NetworkManager has made large stride in its capability and I think a large majority of previous concerns are no longer valid. The only outstanding issue that I've seen brought up is the need for multiple static route tables and if you're configuration is that advanced I imagine a "systemctl disable NetworkManager.service && chkconfig network on" is not going to cause you much pain and despair..... on to more rage!!! :)NOW WHAT??? CONFIG, Y U NO WORK!!?!?!
The first complaint I've heard so far is that the configuration methods from the days of lore utilizing the classic "network" utility powered by our favorite set of scripts will be no more. Alas! The wonderful and whimsical NetworkManager developers have kept this interest in mind and there is /etc/NetworkManager/NetworkManager.conf (which is extremely well documented in 'man 5 NetworkManager.conf') in which we see the line "plugins=ifcfg-rh" by default. What's this little gem mean? Well I'll quote the man page because I'm lazy and don't like rewriting what's already really well written:ifcfg-rh
plugin is used on the Fedora and Red Hat Enterprise Linux distribu-
tions to read and write configuration from the standard /etc/syscon-
fig/network-scripts/ifcfg-* files. It currently supports reading
wired, WiFi, and 802.1x connections, but does not yet support read-
ing or writing mobile broadband, PPPoE, or VPN connections. To allow
reading and writing of these add keyfile plugin to your configura-
tion as well.
CONFIGURE ALL THE THINGS!!!1!#%$%^@#!#!
I'm glad you asked. There is a nice little document located in /usr/share/doc/initscripts-*/ entitled sysconfig.txt that has been a life saver for me and if you weren't aware of this document I suggest you get familiar because it is full of extremely valuable information, but I digress. If you open this file and navigate to the section tagged 'NM_CONTROLLED' you will see the following:NM_CONTROLLED=yes|no
If set to 'no', NetworkManager will ignore this connection/device.
Defaults to 'yes'.
What does this mean? Well ... if you did a fresh install, chances are your interfaces already have this but if you've got a machine that's been upgrading through the timeline to this point, if you just add that little line and fire up NetworkManager it will apply your settings for you. Magic! I know, pretty cool huh? :)
_____________________________ <--- the line where joking stops
In all seriousness, this is a change that is bound to ruffle some feathers but the reality is that with the pace in which Fedora moves it is sometimes best to take the path of least resistance in order to solve a problem and I think that's what's been done here. If there are any real concerns (I mean really valid concerns and not just "I hate change") then I like to believe that the greater community would be willing to entertain them in the proper channels of communication and if necessary then decisions made to fix issues can be altered/modified as needed to suite the needs of the project. I think we as faithful members of the community like to knee jerk react a little too much and I'm 100% guilty of this myself, but I think if we spend some time actually processing the scenarios, possible outcomes and attempt to include as many factors as possible we can see that inclusions of things like NetworkManager into @core aren't there just to add some packages for kicks but that there's actual valid reason. Fedora doesn't change for the sake of change, its changing to make a better project and platform for all to enjoy, and in this case its about squashing bugs so our experience is more pleasant other times it about innovation.... in the end, horray for another closed bug! :)
Happy hacking,
-AdamM
Wednesday, March 21, 2012
Wednesday, March 07, 2012
Fun with bash, libguestfs, rkhunter, and academics.
I recently completed my Masters Degree in Information Assurance and Security which was an amazing experience and I'm so excited to have it completed but that's not the focal point of my blog post. As the walking/talking Fedora fanboi that I am, I did my best to incorporate as much Fedora technology and Open Source Software into my studies as humanly possible. I was extremely fortunate to have a Faculty Advisor who was willing to indulge my Open Source agenda. Along the path of my studies, one thing I found extremely interesting is libguestfs which is primarily (or possibly solely) authored by Richard WM Jones who is a ninja for writing this thing in the first place but was also extremely helpful to me in irc when I was trying to sink my teeth into libguestfs for the first few rounds, so many thanks to him.
I had this idea about private IaaS cloud environments where your cloud infrastructure administrators might not have root access to the VMs running within their datacenters but they still wanted to provide some level of security audits from the hosting side. Now, we can check for exploits running on these systems with standard tools such as nmap, nessus, metasploit and more but what about checking for malicious files on the filesystems themselves? Rootkits? Viruses? $other? Well, this is where the amazing power of libguestfs introduces itself because we can access these things in read-only mode from the level of the hypervisor (which in the case of KVM is/can be a full featured, full fledged OS as it is a hosted hypervisor) without even an account on the virtual machines.
So what can we do with this? Well, I'm sure there are an endless number of possibilities as there often are with topics of this nature but I decided to write a fun proof of concept bash script (there's some awk and coreutils in there, but I generally just lump the family of *nix utils together with "bash" script claims) that will run rkhunter against libvirt guest domains and create a report with a report ID that can be called later to view the report. Now, I'll admit this is not the most elegant implementation of a reporting mechanism because I'm essentially tagging the beginning and ending of a report entry in a text file and running awk across it to produce some basic information about the run but its a proof of concept and its functional! :)
I also wrote a man page and a nice little ncurses (dialog) UI for it, here's some screenshots for kicks:
I titled it gaudit which stands for "Guest Audit" but if someone ever decided to write a tool and wanted the name you're more than welcome to it. I don't plan to have this go anywhere beyond what its done thus far, it was just a lot of fun and I thought I'd share my exploration. Oh, and here's some code. I rolled a rpm as well, SRPM available also.. :)
Source(browse): http://maxamillion.fedorapeople.org/gaudit-0.1/
Source(tar.gz): http://maxamillion.fedorapeople.org/gaudit-0.1.tar.gz
SRPM: http://maxamillion.fedorapeople.org/gaudit-0.1-1.fc16.src.rpm
RPM(noarch): http://maxamillion.fedorapeople.org/gaudit-0.1-1.fc16.noarch.rpm
Like I said, its just a proof of concept but it was a lot of fun to hack on, I hope someone somewhere might find it interesting and maybe ignite an idea to take the general concept further to build a really cool utility! :)
Happy Hacking,
-AdamM
I had this idea about private IaaS cloud environments where your cloud infrastructure administrators might not have root access to the VMs running within their datacenters but they still wanted to provide some level of security audits from the hosting side. Now, we can check for exploits running on these systems with standard tools such as nmap, nessus, metasploit and more but what about checking for malicious files on the filesystems themselves? Rootkits? Viruses? $other? Well, this is where the amazing power of libguestfs introduces itself because we can access these things in read-only mode from the level of the hypervisor (which in the case of KVM is/can be a full featured, full fledged OS as it is a hosted hypervisor) without even an account on the virtual machines.
So what can we do with this? Well, I'm sure there are an endless number of possibilities as there often are with topics of this nature but I decided to write a fun proof of concept bash script (there's some awk and coreutils in there, but I generally just lump the family of *nix utils together with "bash" script claims) that will run rkhunter against libvirt guest domains and create a report with a report ID that can be called later to view the report. Now, I'll admit this is not the most elegant implementation of a reporting mechanism because I'm essentially tagging the beginning and ending of a report entry in a text file and running awk across it to produce some basic information about the run but its a proof of concept and its functional! :)
I also wrote a man page and a nice little ncurses (dialog) UI for it, here's some screenshots for kicks:
I titled it gaudit which stands for "Guest Audit" but if someone ever decided to write a tool and wanted the name you're more than welcome to it. I don't plan to have this go anywhere beyond what its done thus far, it was just a lot of fun and I thought I'd share my exploration. Oh, and here's some code. I rolled a rpm as well, SRPM available also.. :)
Source(browse): http://maxamillion.fedorapeople.org/gaudit-0.1/
Source(tar.gz): http://maxamillion.fedorapeople.org/gaudit-0.1.tar.gz
SRPM: http://maxamillion.fedorapeople.org/gaudit-0.1-1.fc16.src.rpm
RPM(noarch): http://maxamillion.fedorapeople.org/gaudit-0.1-1.fc16.noarch.rpm
Like I said, its just a proof of concept but it was a lot of fun to hack on, I hope someone somewhere might find it interesting and maybe ignite an idea to take the general concept further to build a really cool utility! :)
Happy Hacking,
-AdamM
Wednesday, January 04, 2012
Dell Engineering Preview: Oracle 11gR2 RAC on RHEL6
I've been extremely fortunate to become a part of a really cool research and development organization at Dell just a little over a year ago and I've been working towards publishing some of the fun stuff I've been working on. In recent news I've been able to publish my *very* unsupported tech preview of setting up Oracle 11gR2 RAC (11.2.0.3) on RHEL6 proper (without ASMLib). I hope someone enjoys it and feedback on the related wiki doc would be greatly appreciated. Please note the formatting on the wiki engine we use is a little tough to get used to so my spacing might look a bit odd, I'm working on it, I hope it is found to be useful! :)
The article resides on the Dell TechCenter here:
http://en.community.dell.com/techcenter/b/techcenter/archive/2012/01/03/dell-engineering-preview-oracle-11gr2-rac-on-rhel6.aspx
Happy hacking,
-AdamM
The article resides on the Dell TechCenter here:
http://en.community.dell.com/techcenter/b/techcenter/archive/2012/01/03/dell-engineering-preview-oracle-11gr2-rac-on-rhel6.aspx
Happy hacking,
-AdamM
Subscribe to:
Posts (Atom)