If you are attempting to use OpenSuse 12.1 to build crosstool-NG, you will run into a multitude of small, annoying, but easily fixed problems. I am assuming you have already gotten your OpenSuse system built with the necessary tools to compile software – but there are a few quirks that prevent a proper build of ct-ng that need to be addressed.
First, you will need to fix the inclusion paths for some of the ncurses header files. This fix needs to be put in place just to get ct-ng to install on your system. Edit the file kconfig/nconf.h and change the lines:
This will fix the “missing menu.h” error during the initial config and install of ct-ng.
The next issue you will run into is that ct-ng does not properly compile using GNU make 3.82 (which is the default version of make on OpenSuse 12.1). This can be fixed by choosing the ct-ng option to “Try features marked as EXPERIMENTAL” from the “Paths and misc options” menu. This will enable an additional main menu item called “Companion tools”. In side the “Companion tools” menu, select “Build some companion tools” and then select the option to build “make”.
Finally – at this point, you should be ready to issue the “ct-nt build” command – which will immediately bark at you about not setting LD_LIBRARY_PATH and quit. So, begin your ct-ng build with the following:
LD_LIBRARY_PATH=”” ct-ng build
Assuming you have chosen the appropriate options for the target system you are trying to build, you should be off and running.
NOTE: This does not detail the proper configuration and build process using ct-ng for your target system – nor does it tell you how to use ct-ng. This is just a guide to get around some of the pitfalls you will run into when attempting to use ct-ng on OpenSuse 12.1. The actual use of ct-ng is well outside the scope of this post.
I’ve switched the web site software – again. If you are having trouble with links from other sites or anything you had bookmarked, you’ll need to browse around and locate the content again. I’m going to have forums back online soon and will post some of the major developments that have been made in the release of the Coyote Linux v4.00 distribution. I have made very infrequent posts about its progress as it is steady, but very slow. I think users of previous releases will be very pleased with many of the changes and technology?áenhancements?áthis version will introduce.
I have largely caved to the previous requests to make Coyote a much more all-in-one distribution for those wanting to use the Linux system as a multi-function machine (in addition to just being a firewall). The use of Suse Studio as a base for development has allowed me to add many features (smtp gateway, basic web services, etc) as optional components of the core distribution. While I wouldn’t personally run a border firewall with such features enabled, many users have expressed an interest in the past to have their network edge device/router serve these functions. Such functions will all need to be manually enabled and managed outside of the core Coyote administration interface, but will be available for those wanting a more “complete” Linux distribution for use as their network firewall.
More info to follow shortly.
I recently made a switch from trying to use OpenEmbedded for the Coyote Linux base platform to openSUSE. Specifically, I am now using appliances built at: http://www.susestudio.com/ as my testing platform. My development system is running a full install of SUSE 11.2. I hadn’t really looked at SUSE much in the past – however I am very pleased with its installation, hardware support, desktop, and (IMO) the YaST2 system configuration application is FAR superior to the Red Hat based system management utilities.
If you are a FaceBook user, you can show your support for Coyote Linux by visiting our FB profile and becoming a fan. To visit our FB profile, click here. I will post additional information and send fan updates about Coyote as the distribution continues to develop.
Wolverine 2.10 build 1062 has been released and is available for download from this site. This build of Wolverine does not require activation and all features are available for use without the need to purchase an additional license. This release is the last version of Wolverine that will be made available. Future releases of Coyote Linux will contain all of the features present in this release. Other than the removal of the activation requirement, there are no other feature changes present in this release of Wolverine. To download Wolverine, please use the Downloads link from the menu at the top of the page.
Many of you are going to question some of the decisions made when I selected the tools, platforms, and techniques for the development of Coyote Linux 4. I am going to write up a post as a preemptive set of answers which I will refer to when the questions, comments, flames, etc start pouring in.
One of the biggest changes to this release of Coyote Linux is the use of C# as the primary development language used for most of the administration, configuration, and maintenance utilities. Previous implementations of Coyote Linux made heavy use of C, Pascal (namely Delphi), and Bash shell scripting for this purpose. The change is being made to C# after nearly 2 years of working with the language in a cross-platform setting which involved the use of both Red Hat Linux and Windows 2003/2008 servers. The ability to use a single development environment (in my case, Visual Studio 2008) and produce executables that will execute in unmodified form on both Linux and Windows has seriously put the “R” in RAD programming. I am still actively involved in projects that require the development of cross-platform utilities and am already paying for all of the necessary licenses to provide my company with a full array of software and hardware to develop applications that work in a mixed server OS environment.
I have spent a great deal of time testing C# applications under Linux using Mono as the executing environment. While this is not necessarily the best choice for small, embedded hardware (486 / ARM class processing power) it works very well for anything using i686 or better technology. Another wonderful advantage of using this technology is the ability to run the same set of executables on both 32 and 64 bit hardware without the need for compatibility libraries to be installed. The installation of Mono dictates the 32/64 bit execution environment, preventing the need to recompile the full Coyote Linux software package.
Coyote Linux 4.0 will target 2 installation platforms. The first release of the Coyote Linux security suite will be as an add-on to existing installations of Red Hat or CentOS 5. After the suite has stabilized as an addon for existing distributions, a new installation OS will be added to accommodate the install on bare metal hardware and as both a Xen and VMWare hypervised guest.
The web sites that make up the Coyote Linux and Vortech Consulting customer services, product distribution sites, and e-commerce transaction processing consist of a mix of both Linux and Windows 2008 servers. The design chosen allows me to make use of the last 2 years of my work developing e-commerce and software delivery systems.
If you have any further questions or comments, you are welcome to visit the forums or post a comment to this blog.
Wolverine 2.01 build 1015 is available for download. This release corrects a problem with the PPTP service which can cause a system crash. Anyone running Wolverine 2.01 which reports a kernel version of 188.8.131.52 should upgrade to this release if you plan to make use of the PPTP services.
Wolverine 2.01.1008 is available for download. This is the first release candidate for the 2.01 series. Build 1008 includes an updated kernel and web admin bug fixes (namely for the PPTP and IPSEC configuration reloads which caused the VPN services to stop working in some cases).
Coyote Linux 3.00 build 46 has been released and contains initial QoS support and many bug fixes merged from the current Wolverine development tree. For more information, please see the Coyote Linux Personal Firewall forum.
Wolverine 2.01 build 1000 has been released and contains initial QoS/Traffic shaping support along with several small bug fixes to the web front-end and startup scripts.