Jun
18
2009
0

Remote Upgrades on Fedora based Systems

I’m doing a remote upgrade on a test server at work(VoiceIP Solutions). So today’s article will cover upgrading from Fedora 6 to Fedora 10. Before you start, backup any important data! Every once in a while some dependency issue will crop up that blows up your server.  Also upgrading from Fedora 6 to Fedora 11 is not as easy as say, upgrading from Fedora 10 to Fedora 11.  So be careful and upgrade on a regular basis!

The Goals of this Post:

– remote upgrade from Fedora 6 to Fedora 10

(more…)

Apr
02
2009
5

How to configure a Polycom SoundPoint IP phone for Asterisk on Fedora 10

In my opinion the best IP business phones on the market are made by Polycom. Anyone that knows anything about the VoIP Industry knows that!  High quality Polycom desk phones combined with Asterisk are a great combination of quality/price. So to that end we’re doing this lab.

Polycom employs several methods of provisioning the SIP phones.  For general configuration Sound Point IP have an excellent built web GUI,  but for multiple phones Polycom has an XML based system as well.  Every Sound Point IP can be provisioned based on MAC address.  Polycom’s provisioning method makes use of TFTP, FTP, or HTTP to deliver firmware updates and individual phone settings.

The goals of this post:

– Configure FTP server for Polycom firmware and configuration

– Configure Asterisk SIP extension

– deploy firmware and XML configuration files to Polycom SoundPoint IP 501 SIP phone

(more…)

Mar
22
2009
2

Fedora 11 will likely not include Xen Dom0 (virtualization) support

xen logo

I (like many of you) have been patiently waiting since Fedora 8 for Dom0(Domain 0) Xen support in Fedora.  Why hasn’t Red Hat or the Fedora Project made an announcement? Haven’t we been good? I mean libvirtd is great and all, but Xen PV(paravirtualized) VM’s destroy. I did some googling to get to the bottom of this. I found a fedora project page with a January 2009 status update.

Here is a snipit:

“Currently, the Fedora kernel-xen package is based on forward-porting of the XenSource patches from 2.6.18 to more recent kernel versions. This has many problems, including:

  • XenSource code has no chance of being merged upstream, in the near future, making the forward-porting work needed for all new kernel versions.
  • Lots of porting work for each new kernel version
  • Because of the above, kernel-xen has been some releases behind the non-xen kernel package, and the lag between kernel and kernel-xen has been increasing constantly”

And also:

“As of November 2007, the kernel-xen forward-porting was being finished for 2.6.22, and Linux 2.6.24 was about to be released. The effort needed for 2.6.23, 2.6.24 and later would have been even bigger with the introduction of paravirt_ops and the i386-x86_64 merge upstream. Thus, the decision was made to abandon the forward-porting effort and focus on upstream paravirt_ops.”

So where does this leave us?  Unmodified guest are old news.  Even Microsoft can do that.  Well not really, as I understand it, Microsoft’s HyperV platform contains Xensource licensed code.  But a customer of the company I work for likes HyperV a lot(incidently).  On the Xen Wiki it says that Paravirt_ops will be ported to the 2.6.30 kernel.  My prediction, Xen Dom0 support will be available toward the end of Fedora 11’s cycle or Fedora 12.

Why does Dom0 matter?  Dom0 is the specially modifed Xen-linux kernel that sits on top of the hypervisor. From Dom0 you can run fully virtualized guest and partially virtualized guest (paravirtualization).  Paravirtualized guest enjoy a method for allowing the use of a set of generic virtual device drivers provided by Dom0.  PV guest are known to have outstanding perfomance compared to their fully virtualized counterpart.  Paravirt_ops refers to Dom0 integration with the Linux kernel.

Feb
28
2009
0

UPDATE: Using Multiple interfaces with KVM and Xen

I had a system crash with blinking keyboard lights. The error has something to do with either ACPI power states or the bridge interface. On my system setting br1 to DHCP causes some kind of issue when using DHCP, here is my log:

Feb 26 03:25:29 mattcom1 dhclient: DHCPREQUEST on br1 to 255.255.255.255 port 67
Feb 26 03:25:29 mattcom1 ntpd[2188]: Listening on interface #22 eth0_rename, 192.168.1.254#123 Enabled
Feb 26 03:25:29 mattcom1 avahi-daemon[2374]: Registering new address record for fe80::20a:5eff:fe45:7eca on eth1.*.
Feb 26 03:25:30 mattcom1 avahi-daemon[2374]: Registering new address record for fe80::20a:5eff:fe45:7eca on br1.*.
Feb 26 03:25:31 mattcom1 ntpd[2188]: Listening on interface #23 br1, fe80::20a:5eff:fe45:7eca#123 Enabled
Feb 26 03:25:32 mattcom1 dhclient: DHCPREQUEST on br1 to 255.255.255.255 port 67
Feb 26 03:25:32 mattcom1 kernel: ————[ cut here ]————
Feb 26 03:25:32 mattcom1 kernel: WARNING: at net/core/dev.c:1505 skb_gso_segment+0×6e/0×153() (Tainted: P )
Feb 26 03:25:32 mattcom1 kernel: Hardware name:
Feb 26 03:25:32 mattcom1 kernel: Modules linked in: sit tunnel4 udf fuse bridge stp bnep sco l2cap bluetooth sunrpc ipv6 cpufreq_ondemand acpi
_cpufreq dm_multipath kvm_intel kvm uinput snd_ens1371 gameport snd_rawmidi snd_ac97_codec ac97_bus nvidia(P) snd_seq_dummy snd_seq_oss snd_se
q_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd iTCO_wdt e1000e iTCO_vendor_support soundcore ppdev 3c59x
firewire_ohci snd_page_alloc firewire_core i2c_i801 parport_pc mii floppy parport i2c_core pcspkr crc_itu_t ata_generic pata_acpi sha256_gener
ic cbc aes_i586 aes_generic dm_crypt crypto_blkcipher [last unloaded: microcode]

then later…

Feb 26 03:52:06 mattcom1 kernel: qemu-kvm[10261]: segfault at 1df ip 080afcb8 sp bfed6898 error 4 in qemu-kvm[8047000+175000]
Feb 26 03:52:06 mattcom1 avahi-daemon[2374]: Withdrawing address record for fe80::3c3b:13ff:fedb:cfcb on vnet0.
Feb 26 03:52:06 mattcom1 kernel: br1: port 2(vnet0) entering disabled state
Feb 26 03:52:06 mattcom1 kernel: device vnet0 left promiscuous mode
Feb 26 03:52:06 mattcom1 kernel: br1: port 2(vnet0) entering disabled state
Feb 26 03:52:07 mattcom1 ntpd[2188]: Deleting interface #27 vnet0, fe80::3c3b:13ff:fedb:cfcb#123, interface stats: received=0, sent=0, dropped
=0, active_time=1289 secs

So I set br1 to a static IP and seems to work, though since it is a bridge I don’t see why it needs an IP address anyways… so turn it off by editing the bridge and the real interface to have no IP.

-Matt

/etc/sysconfig/network-scripts/ifcfg-br:

DEVICE=br1
TYPE=Bridge
ONBOOT=yes
BOOTPROTO=static
NM_CONTROLLED=no