Karel,
Thanks for the detailed report. Would you mind re-posting this to the
xen-devel mailing list?
Thanks,
-Georeg
On Thu, May 24, 2018 at 9:47 AM, Karel Hendrych <k+centosvirt(a)karlos.cz> wrote:
> Bump. Folks, any ideas?
>
> Cheers
> Karel
>
>
> On 22.5.2018 11:33, Karel Hendrych wrote:
>>
>> Hi, I am seeing frequent libvirtd hangs (clients not responding) after
>> last CentOS6-Xen update :
>>
>> libvirt-libs-4.1.0-2.xen46.el6.x86_64
>> libvirt-daemon-4.1.0-2.xen46.el6.x86_64
>> libvirt-daemon-driver-network-4.1.0-2.xen46.el6.x86_64
>> libvirt-daemon-driver-nwfilter-4.1.0-2.xen46.el6.x86_64
>> libgcc-4.4.7-18.el6_9.2.x86_64
>> 2:qemu-img-0.12.1.2-2.503.el6_9.5.x86_64
>> libvirt-daemon-driver-storage-core-4.1.0-2.xen46.el6.x86_64
>> libvirt-daemon-driver-secret-4.1.0-2.xen46.el6.x86_64
>> libvirt-daemon-driver-interface-4.1.0-2.xen46.el6.x86_64
>> libvirt-daemon-driver-nodedev-4.1.0-2.xen46.el6.x86_64
>> 10:centos-release-xen-common-8-4.el6.x86_64
>> xen-licenses-4.6.6-12.el6.x86_64
>> xen-libs-4.6.6-12.el6.x86_64
>> libvirt-daemon-driver-libxl-4.1.0-2.xen46.el6.x86_64
>> libvirt-daemon-driver-xen-4.1.0-2.xen46.el6.x86_64
>> libvirt-daemon-driver-qemu-4.1.0-2.xen46.el6.x86_64
>> libvirt-daemon-driver-storage-gluster-4.1.0-2.xen46.el6.x86_64
>> libvirt-daemon-driver-storage-logical-4.1.0-2.xen46.el6.x86_64
>> libvirt-daemon-driver-storage-mpath-4.1.0-2.xen46.el6.x86_64
>> libvirt-daemon-driver-storage-disk-4.1.0-2.xen46.el6.x86_64
>> libvirt-daemon-driver-storage-scsi-4.1.0-2.xen46.el6.x86_64
>> libvirt-daemon-driver-storage-iscsi-4.1.0-2.xen46.el6.x86_64
>> libvirt-daemon-driver-storage-4.1.0-2.xen46.el6.x86_64
>> libstdc++-4.4.7-18.el6_9.2.x86_64
>> libvirt-daemon-config-nwfilter-4.1.0-2.xen46.el6.x86_64
>> libvirt-daemon-config-network-4.1.0-2.xen46.el6.x86_64
>> libvirt-daemon-driver-lxc-4.1.0-2.xen46.el6.x86_64
>> libvirt-client-4.1.0-2.xen46.el6.x86_64
>> linux-firmware-20171215-82.git2451bb22.el6.noarch
>> 12:dhcp-common-4.1.1-53.P1.el6.centos.4.x86_64
>> 12:dhclient-4.1.1-53.P1.el6.centos.4.x86_64
>> libvirt-4.1.0-2.xen46.el6.x86_64
>> 10:centos-release-xen-46-8-4.el6.x86_64
>> 10:centos-release-xen-44-8-4.el6.x86_64
>> tzdata-2018e-3.el6.noarch
>> libgomp-4.4.7-18.el6_9.2.x86_64
>> kernel-4.9.86-30.el6.x86_64
>> xen-hypervisor-4.6.6-12.el6.x86_64
>> xen-runtime-4.6.6-12.el6.x86_64
>> xen-4.6.6-12.el6.x86_64
>> libvirt-daemon-xen-4.1.0-2.xen46.el6.x86_64
>>
>> Remedy is to kill -9 libvirtd and start again. Issue can be replicated
>> within few domU starts. Usually libvirtd hangs when domU is bringing up xen
>> drivers or something around udev, like:
>>
>> xen_netfront: Initialising Xen virtual ethernet driver
>>
>> I've been looking into libvirtd strace and debug logs, so far most
>> suspicious in libvirtd debug log is this:
>>
>> libvirtd.log:2018-05-22 08:32:44.760+0000: 25455: debug :
>> udevRemoveOneDevice:1289 : Failed to find device to remove that has udev
>> name '/sys/devices/vif-24-0/net/vif24.0/queues/tx-7'
>> libvirtd.log:2018-05-22 08:32:44.761+0000: 25455: debug :
>> udevRemoveOneDevice:1289 : Failed to find device to remove that has udev
>> name '/sys/devices/vif-24-0/net/vif24.0/queues/tx-6'
>> libvirtd.log:2018-05-22 08:32:44.761+0000: 25455: debug :
>> udevRemoveOneDevice:1289 : Failed to find device to remove that has udev
>> name '/sys/devices/vif-24-0/net/vif24.0/queues/tx-4'
>> libvirtd.log:2018-05-22 08:32:44.762+0000: 25455: debug :
>> udevRemoveOneDevice:1289 : Failed to find device to remove that has udev
>> name '/sys/devices/vif-24-0/net/vif24.0/queues/tx-5'
>> libvirtd.log:2018-05-22 08:32:44.763+0000: 25455: debug :
>> udevRemoveOneDevice:1289 : Failed to find device to remove that has udev
>> name '/sys/devices/vif-24-0/net/vif24.0/queues/tx-2'
>> libvirtd.log:2018-05-22 08:32:44.764+0000: 25455: debug :
>> udevRemoveOneDevice:1289 : Failed to find device to remove that has udev
>> name '/sys/devices/vif-24-0/net/vif24.0/queues/tx-3'
>> libvirtd.log:2018-05-22 08:32:44.765+0000: 25455: debug :
>> udevRemoveOneDevice:1289 : Failed to find device to remove that has udev
>> name '/sys/devices/vif-24-0/net/vif24.0/queues/rx-6'
>> libvirtd.log:2018-05-22 08:32:44.766+0000: 25455: debug :
>> udevRemoveOneDevice:1289 : Failed to find device to remove that has udev
>> name '/sys/devices/vif-24-0/net/vif24.0/queues/rx-5'
>> libvirtd.log:2018-05-22 08:32:44.767+0000: 25455: debug :
>> udevRemoveOneDevice:1289 : Failed to find device to remove that has udev
>> name '/sys/devices/vif-24-0/net/vif24.0/queues/rx-4'
>> libvirtd.log:2018-05-22 08:32:44.767+0000: 25455: debug :
>> udevRemoveOneDevice:1289 : Failed to find device to remove that has udev
>> name '/sys/devices/vif-24-0/net/vif24.0/queues/rx-7'
>> libvirtd.log:2018-05-22 08:32:44.768+0000: 25455: debug :
>> udevRemoveOneDevice:1289 : Failed to find device to remove that has udev
>> name '/sys/devices/vif-24-0/net/vif24.0/queues/rx-2'
>> libvirtd.log:2018-05-22 08:32:44.769+0000: 25455: debug :
>> udevRemoveOneDevice:1289 : Failed to find device to remove that has udev
>> name '/sys/devices/vif-24-0/net/vif24.0/queues/rx-3'
>>
>> I could not get rid of this by reducing amount of driver queues (not sure
>> if that applies to PV)
>>
>> Is someone out there seeing similar issues? Anyone perhaps interested in
>> reviewing full debug log / strace ?
>>
>> Cheers
>> Karel
>>
>> _______________________________________________
>> CentOS-virt mailing list
>> CentOS-virt(a)centos.org
>> https://lists.centos.org/mailman/listinfo/centos-virt
>
> _______________________________________________
> CentOS-virt mailing list
> CentOS-virt(a)centos.org
> https://lists.centos.org/mailman/listinfo/centos-virt
On Wed, 2007-02-28 at 03:22 +0800, mcclnx mcc wrote:
>
> We installed BMR boot server version 6.0 on DELL server. This DELL
> server have CENTOS 3.7 in it. We got error message when we tried to
> use "bmrsrtadm". Anyone know how to fix it or work
> around? ./bmrsrtadm Select one of the following options:
> 1. Create a new Shared Resource Tree. 2. Create a new CD image
> based Shared Resource Tree. 3. Copy an existing Shared Resource
> Tree to a new location. 4. Modify an existing Shared Resource
> Tree. 5. Delete an existing Shared Resource Tree. 6. List
> Shared Resource Trees available on this server. 7. Quit.
> Enter your selection (1-7) [1] : 1 Enter the name of the SRT to
> create : centos35 Enter the description of the new SRT : blade
> V-128-312 Unsupported Linux release: CentOS release 3.7
> (Final) V-128-312 Unsupported Linux release: CentOS release 3.7
> (Final) Enter the directory in which to place the new SRT
> [/export/srt] : /usr/openv/net backup
> V-125-419 /usr/openv/netbackup/baremetal/server/data/createsrt.conf:
> internal er ror - failed to load SRT/BI contents for platform
> "i686-RHEL-" V-125-39 caught exception: runtime error in
> srtPlat.cpp:PackageInfo::PackageInfo () [Error] V-125-40 Platform
> initialization failed. Please review logs for addition al diagnostic
> information. Removing SRT "centos35" from server -- please stand
> by ...
> _________________________________________________________________
>
> ___________________________________________________
> 您的生活即時通 - 溝通、娛樂、生活、工作一次搞定!
> http://messenger.yahoo.com.tw/
Can't respond with any direct experience on your issue, except to guess
that putting something that look more like the installer would expect to
find on a real RHEL3 installation in /etc/redhat-release might help;
however, you could increase the probability of getting good help by not
sending HTML mail in a virtually unintelligible format.
Phil
My network installation via PXE breaks when graphical installation starts,
here my program.log:
Running... /bin/mount -n -t auto -o ro,loop=/dev/loop0 /tmp/install.img
/mnt/runtime
07:51:29,617 INFO : Running... ['udevadm', 'trigger', '--action=add',
'--subsystem-match=net']
07:51:29,660 INFO : Running... ['udevadm', 'trigger', '--action=add',
'--subsystem-match=block']
07:51:29,812 INFO : Running... ['udevadm', 'settle', '--timeout=300']
07:51:30,454 INFO : Running... ['udevadm', 'trigger', '--action=add',
'--subsystem-match=net']
07:51:30,494 INFO : Running... ['udevadm', 'settle', '--timeout=300']
07:51:33,182 INFO : Running... ['metacity', '--display', ':1',
'--sm-disable']
07:51:33,689 ERROR : Window manager warning: 0 stored in GConf key
/desktop/gnome/peripherals/mouse/cursor_size is out of range 1 to 128
07:51:35,442 INFO : Running... ['xrandr', '-q']
07:51:35,458 INFO : Screen 0: minimum 320 x 200, current 1280 x 1024,
maximum 1280 x 1024
07:51:35,458 INFO : default connected 1280x1024+0+0 0mm x 0mm
07:51:35,459 INFO : 1280x1024 60.0* 75.0
07:51:35,459 INFO : 1280x960 60.0
07:51:35,459 INFO : 1280x854 75.0 60.0
07:51:35,459 INFO : 1280x800 75.0 60.0
07:51:35,459 INFO : 1152x864 75.0 60.0
07:51:35,460 INFO : 1280x768 75.0 60.0
07:51:35,460 INFO : 1280x720 75.0 60.0
07:51:35,460 INFO : 1024x768 75.0 70.0 60.0
07:51:35,460 INFO : 1024x576 75.0 60.0
07:51:35,461 INFO : 960x600 60.0
07:51:35,461 INFO : 832x624 75.0
07:51:35,461 INFO : 960x540 60.0
07:51:35,461 INFO : 800x600 75.0 72.0 60.0 56.0
07:51:35,462 INFO : 768x576 60.0
07:51:35,462 INFO : 720x576 60.0
07:51:35,462 INFO : 856x480 60.0
07:51:35,462 INFO : 848x480 60.0
07:51:35,462 INFO : 800x480 75.0 60.0
07:51:35,463 INFO : 720x480 61.0
07:51:35,463 INFO : 640x480 75.0 73.0 67.0 60.0
07:51:35,463 INFO : 720x400 70.0
07:51:35,463 INFO : 640x400 72.0
07:51:35,464 INFO : 512x384 60.0
07:51:35,464 INFO : 400x300 60.0
07:51:35,464 INFO : 320x240 61.0
07:51:35,464 INFO : 320x200 71.0
07:51:35,464 ERROR : xrandr: Failed to get size of gamma for output
default
07:51:37,200 ERROR : Window manager warning: Buggy client sent a
_NET_ACTIVE_WINDOW message with a timestamp of 0 for 0x80000d (CentOS Ins)
07:51:37,201 ERROR : Window manager warning: meta_window_activate called
by a pager with a 0 timestamp; the pager needs to be fixed.
I tried to change monitor but I got the same result.
Hello,
I'd like to announce a release of a CentOS 5 DVD image, with i386 and
x86_64 installations.
This is an independent work, so please don't bother CentOS lists with
bugs related to the installer only.
Summary of changes:
* i686 and x86_64 install from a single dvd (automatic detection on boot)
* updates as of 2007-04-26
* no kdelibs-api-docs, openoffice.org, tetex-doc and most *-javadoc
sha1sum: 63885249695c60a87443e304212d6cf9af678165 centos5_32and64.iso
md5sum: 0db291c3e4f7dc4fb4e6ea052b77e95d centos5_32and64.iso
torrent: ftp://ftp.gil.di.uminho.pt/pub/users/strange/centos/c5_32+64.torrent
iso: ftp://ftp.gil.di.uminho.pt/pub/users/strange/centos/centos5_32and64.iso
Detailed changes:
* All rpms are the originals from CentOS 5. However, the *.i386.rpm and
*.noarch.rpm for the x86_64 are the ones from the i386 DVD, not from the
x86_64, as the contents are the same and the rpm headers differ only on
the Build Date and/or Signature.
* each install (x86_64 or i386) only has knowledge of rpms originally in their
DVDs, so x86_64 installs won't be bloated with more i386 packages than the
originals.
* Some packages are missing. It's a pity some subpackages that don't
depend on %arch are still built as .%arch.rpm, but there's nothing I'm
willing to do about that. The missing packages are:
- openoffice.org
- tetex-doc
- kdelibs-apidocs
- Deployment_Guide, except for en_US and pt-BR
- *-javadoc, except for:
- java-1.4.2-gcj-compat-javadoc (required by eclipse)
- bsh-javadoc and xmlrpc-javadoc (part of java-devel group)
Note that both Deployment_Guide and openoffice.org have updates, so if you
don't care about kdelibs-apidocs, tetex-doc and *-javadoc, you can still
use this image as a local base.
* The updates as of 2007-04-26 from CentOS replace their originals:
- autofs-5.0.1-0.rc2.43.0.2
- bind-9.3.3-8
- cups-1.2.4-11.5.1
- Deployment_Guide-(en-US and pt_BR)-5.0.0-21
- dhcp-3.0.5-5
- ekiga-2.0.2-7.0.2
- emacs-21.4-18.1
- evolution-data-server-1.8.0-15.0.2
- file-4.17-9
- firefox-1.5.0.10-2.el5
- freetype-2.2.1-17
- gcc-4.1.1-52.el5.2
- gnupg-1.4.5-13
- kernel-2.6.18-8.1.1
- krb5-1.5-23
- libwpd-0.8.7-3
- libX11-1.0.3-8.0.1
- libXfont-1.2.2-1.0.2
- module-init-tools-3.3-0.pre3.1.16.0.1
- net-snmp-5.3.1-14.0.1
- nss-3.11.5-3.el5
- php-5.1.6-11
- postgresql-8.1.8-1
- samba-3.0.23c-2.el5.2
- spamassassin-3.1.8-2
- squid-2.6.STABLE6-4
- thunderbird-1.5.0.10-1.el5
- tzdata-2007d-1
- virt-manager-0.2.6-7.0.2
- wireshark-0.99.5-1
- xen-3.0.3-25.0.3
- xorg-x11-apps-7.1-4.0.1
- xorg-x11-server-1.1.1-48.13.0.1
- yelp-2.16.0-14.0.1
* automatic detection on boot for i386 or x86_64 install
- default label linux now calls com32 module l32or64 (attachment l32or64.c)
that selects 32 or 64 bits kernel according to long_mode flag in cpuid
- new boot targets linux32 and linux64 that force 32 bit or 64 kernel
* single 32 bits initrd for i386 and x86_64
- new /init (attachment renmod.c), that symlinks /modules to the
correct version
- /modules.i386 with the original modules from the i386 initrd
- /modules.x86_64 with the original modules from the x86_64, but with the
paths in modules.cgz changed to $kver/i686/ instead of the original
$kver/x86_64/, as the anaconda loader was looking there for the modules
(it's probably ignoring the run-time arch and relying on the compile
time one)
- the space savings from using a single initrd aren't that much (1.5), so
using the two separated initrds is still feasible (and l32or64 supports
it), but the x86_64 initrd needs it's .buildstamp replaced with the one
from i386.
* single 32 bits minstage2 and stage2
- anaconda support for space separated list of available archs in
.discinfo (attachment discinfo.patch) (anaconda has at least 4 different
places where it parses the .discinfo file. something should be done
about that!)
- yum support for repodata.%arch location (attachment repodata.arch.patch):
-> repodata.i386 and repodata.x86_64
(there was a supposed fallback to repodata if no repodata.%arch existed,
but it didn't work in my tests, so you won't be able to use these stages
with original repositories for network installs (ln -s repodata
repodata.x86_64 or repodata.i386 should be enough, though))
- runtime replacing of usr/lib/rpm/macros with the correct one for the
arch (attachment rpm_macros.patch)
usr/lib/rpm/macros.i386 from i386/images/stage2/usr/lib/rpm/macros
usr/lib/rpm/macros.x86_64 from x86_64/images/stage2/usr/lib/rpm/macros
ln -fs /tmp/rpmmacros usr/lib/rpm/macros
- symlinks for directories or files with i386/i686 in their name, with
i386/i686 replaced with x86_64 (not sure if this was needed, but I
didn't feel like making more tests):
ln -s i686-redhat-linux-gnu etc/gtk-2.0/x86_64-redhat-linux-gnu
ln -s i386-redhat-linux-gnu etc/pango/x86_64-redhat-linux-gnu
ln -s keymaps-override-i386 usr/lib/anaconda-runtime/keymaps-override-x86_64
ln -s screenfont-i386.gz usr/lib/anaconda-runtime/screenfont-x86_64.gz
ln -s i386-redhat usr/share/grub/x86_64-redhat
To recreate the image with your own packages or comps.xml:
1. populate the CentOS rpm directory with the rpms of your choosing;
2. call createrepo in the iso root dir:
createrepo -g path_to_comps.xml .
3. rename repodata to repodata.i386 or repodata.x86_64 and fix the
relative paths in repodata.%arch/repomd.xml:
perl -pi -e 's/repodata/repodata.i386/g' repodata.i386/repomd.xml
4. repeate for the other arch.
5. create the iso:
mkisofs -o ../centos5_32and64.iso -b isolinux/isolinux.bin \
-c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table \
-r -pad -J -joliet-long -V "CentOS" .
6. add checksum to iso:
implantisomd5 ../centos5_32and64.iso
7. record it:
growisofs -Z /dev/cdrom=../centos5_32and64.iso
--
lfr
0/0
On Wed, 2005-06-29 at 16:42 -0700, dan.trainor wrote:
> Hello, all -
>
> I've been throwing the question around on the kickstart-list for the
> last few days here, and can't quite get ahold of things. Please, allow
> me to explain.
>
> I am in the process of making a custom CentOS/RHEL kickstart install.
> It works well right now; however, it's a hackjob, and I am not
> comfortable with it as of yet.
>
> For the past few days, I've even gone as far as making a custom
> comps.xml file, for the purpose of the kickstart. What I'd like to do
> is not include any @groups or -/+files in my kickstart file; rather, I'd
> like to edit comps.xml's @Base and @Core so that I need nothing else in
> my kickstart file, except for the configuration options. I know that
> this isn't required, I'm just anal about the whole situation ;)
>
> This would also give me a chance to package, along with my install,
> newer and updated packages/RPMs so that I don't have to run an update
> process on the newly installed machine. My understanding is, if this is
> done, a new base/hdlist{2} file{s} is/are needed to be created. I've
> read around a bit, and apparently I'm supposed to use a tool named
> "genhdlist", but I've not been able to find any documentation on this
> tool, what exactly it does, and how exactly to use it.
genhdlist is part of anaconda-runtime
Here is some good info:
http://fedoraproject.org/wiki/Anacondahttp://fedoraproject.org/wiki/AnacondaBinaries
Here is all the stuff you need to run the anaconda binaries:
http://fedoraproject.org/wiki/AnacondaBuildEnvironment
(Although anaconda is very much undocumented)
>
> I'm expressing my frustration, along with many other people who have
> been in the same situation, as seen from the kickstart-list.
>
> I guess what I'm asking for, is if someone has ever made a completely
> custom kickstart install that does the following:
>
> 1) edits comps.xml to modify @base and @core
> 2) takes newer packages into consideration
> 3) compiles this information, creates new hdlist{2} reference files
> 4) gets the mother to work.
>
> This seemingly simple process seems to lack a bit of documentation. I
> ahve found sniplets all over the 'net where it would show a small
> process of how to get all this done, however, the author fails to
> document the utility or method in detail, or the process is for
> something totally archaic such as RH6.2.
>
> Any help would be greatly appreciated.
Here is the script I use to build the ISOs from the main tree:
http://centos.hughesjr.com/testing/build.sh.txt
On 25 March 2016 at 16:31, Matthew Miller <mattdm(a)mattdm.org> wrote:
> On Fri, Mar 25, 2016 at 11:26:17AM +0000, Timothy Murphy wrote:
> > >> I'n wondering if it is possible to have Centos-7 automatically change
> > >> firewall zones, depending on the network we conect to.
> > > The way to do this is changing the zone for the network in
> > > NetworkManager.
> > Are there two different ways of setting firewalld zones,
> > in firewalld and in NetworkManager?
> > Which is taken if they differ?
>
> They can't differ — the configuration is stored in the ifcfg files, no
> matter how you set it.
>
>
>
In this instance you're incorrect Matthew.
If an interface is associated with a zone via firewalld then this config is
in /etc/firewalld/zones/<zonename>.xml with an interface element in the xml
there.
If NM has connection.zone modified to point to something this then would go
into /etc/sysconfig/network-scripts/ifcfg-* (as ZONE=)
And as a quick test the NM value overrides the firewalld one.
To verify this in a VM, assuming an interface name of eth0, do the
following:
== Make the firewalld change ==
firewall-cmd --change-interface=eth0 --zone=work
firewall-cmd --runtime-to-permanent
== Verify the config ==
firewall-cmd --get-active-zones
cat /etc/firewalld/zones/work.xml
** At this point the config all points to eth0 in work and verification
confirms this **
== Make the NM change ==
nmcli c mod "System eth0" connection.zone home
== Verify the config ==
firewall-cmd --get-active-zones
cat /etc/sysconfig/network-scripts/ifcfg-eth0
cat /etc/firewalld/zones/work.xml
** At this point the firewalld config points to eth0 in work but the NM
config points to home and verification confirms this different config but
home in use **
== Note the persistence ==
reboot
firewall-cmd --get-active-zones
cat /etc/sysconfig/network-scripts/ifcfg-eth0
cat /etc/firewalld/zones/work.xml
** The same stituation pre reboot appears **
I assume this is the case as NM explicitly puts an interface into a zone as
part of the connection profile coming up. I haven;t monitored dbus to see
if firewalld brings it up on one and NM changes it or not... easy for
someone else to test though ;)
> I find the firewalld definition of "zones" rather confusing.
> > I run shorewall on my home server, and that seems to me
> > to have a much simpler definition of zones.
>
> Think of "zone" as "set of presets".
>
It's a really horrible UX issue frankly, I've seen it confuse many people
at this point. This is made worse by the Fedora products creating their own
zones and defaulting to those with EL7 using the firewalld upstream default
of Public, which the name itself is confusing when it doesn't really
relate to anything Public but is just a name.
I've seen people assume work or home are detected by subnets or local net
only for instance - when again it's just labels for the larger part,
Upstream firewalld has been reluctant to change this though from what I've
seen and you can't even remove the default zones nicely to get a clearer
view of things.
At 04:15 PM 12/27/2005, Bryan J. Smith wrote:
>Robert Moskowitz <rgm(a)htt-consult.com> wrote:
>
>
> > At any time I could have switched to a single executing
> > copy of Eudora with multiple personalities.
> > But I chose not to.
>
>Eudora is not designed for the 1:1 setup.
>Outlook Express is not designed for the 1:1 setup.
>[Mozilla] Thunderbird is not designed for the 1:1 setup.
>
>As an enterprise administrator, I want a 1:1
>user:object-framework setup when users login.
This part of the reason why the IT folks and us research/testing
folks tend to get at loggerhead!
Why I would never make the move ot Outlook. But I see I will be
peeling the cover off of Thunderbird.
>In addition to having the ability and separation of multiple
>e-mail accounts, the "Personalities" are called "Profiles" in
>Thunderbird. By default, the "default" profile is always
>used (and _not_ prompted for) in Thunderbird.
>
>Here's how you launch the profile manager in various OSes for
>Thunderbird:
> http://www.mozilla.org/support/thunderbird/profile
Sometime in the past I used this with Netscape 7, perhaps? So it all
started coming 'back' to me.
>Namely, you need to pass the "-profilemanager" option.
>
>Once you have multiple profiles, when you launch Thunderbird,
>it will prompt you for which one (unless you click the box
>"Don't ask at startup").
>
>If you already have one running, you will want to pass the
>option again. Otherwise, the currently running profile may
>be assumed.
I see that running multiple Thunderbirds doesn't work according to
this article, but I wonder if this is a windows centric answer, not
applying to unix.
http://kb.mozillazine.org/Run_multiple_copies_of_Thunderbird_at_the_same_ti…
> > I run the others a couple times a day (desktop DOES get
> > cluttered and memory consumed).
> > All the work documents and mail are organized by identity.
> > So I am leaning more and more to separate linux users.
>
>No, that's _overkill_ for what you want.
good!
> > After finding more gnome documentation, I see they call
> > them workspaces.
>
>Yes, I know. Desktops, workspaces, viewports, etc... In
>old, original "virtual window manager" speak, it's the
>"pager." The idea that you can "page around" multiple areas
>of the X session so it seems you have a much bigger desktop
>than normal.
And when you did, you brought the network to a standstill. I
'caught' some of our unix support people doing this with our network
sniffer. After that we got a LOT more memory for those X-terminals
so that they were not always getting refreshes from their clients (it
was always a lot of fun with Xwindows and SNMP in explaining that
they had the client/server model reversed).
> > But then we are not running the same Un*x on the same
> > platforms, terminals, networks that we were then.
>
>Who says? The concepts are _exactly_ the _same_ today on
>Linux!
But at least now we have the memory and processor to support this.
Motorla tried to sell us a system and showed our execs how they ran
it in their office. Seemed so nice and efficient. I was able to
figure out that they were running a FDDI backbone and only 5
workstations per ethernet segment (all routed).
The concepts have not changed. The hardware finally caught up.
Did you see that John Diebold passed away. Now THERE was a man
proposing solutions a decade or more before they became 'real'.
>1984 c/o MIT and Digital (among others). It was loosely
>based on "w", which pre-dates even Apple's Lisa (circa 1982).
That Lisa was an abomination.
>[ **NOTE: The next-generation of GNOME is adopting the .NET
>object framework, so objects and applications will be at
>least source-code compatible with MS .NET, if not Common
>Language Runtime (CLR) compatible. The same people behind
>the open Mono implementation were the same people who
>designed GNOME -- and they work for Novell who purchased
>Ximian. ]
Maybe I should move to KDE now? 8-)
>Citrix began around '90 on OS/2. The OS/2 kernel, unlike the
>NT kernel (with its GDI requirement), could support multiple
>sessions, and run a GUI atop of each session.
The thing that killed OS/2 was the lack of TCP/IP support. I had
kludged FTP software's drivers in, but the pain was more than Windows
3.0 with either FTP's or Novell's stack.
>But what really made Citrix was their NT 3.51 hack that
>results in MetaFrame.
And I won't go into the many problems this caused me. Mostly becuase
the scars are healed on only the memory of them are left.
On Wed, 2005-06-29 at 19:02 -0500, Johnny Hughes wrote:
> On Wed, 2005-06-29 at 16:42 -0700, dan.trainor wrote:
> > Hello, all -
> >
> > I've been throwing the question around on the kickstart-list for the
> > last few days here, and can't quite get ahold of things. Please, allow
> > me to explain.
> >
> > I am in the process of making a custom CentOS/RHEL kickstart install.
> > It works well right now; however, it's a hackjob, and I am not
> > comfortable with it as of yet.
> >
> > For the past few days, I've even gone as far as making a custom
> > comps.xml file, for the purpose of the kickstart. What I'd like to do
> > is not include any @groups or -/+files in my kickstart file; rather, I'd
> > like to edit comps.xml's @Base and @Core so that I need nothing else in
> > my kickstart file, except for the configuration options. I know that
> > this isn't required, I'm just anal about the whole situation ;)
> >
> > This would also give me a chance to package, along with my install,
> > newer and updated packages/RPMs so that I don't have to run an update
> > process on the newly installed machine. My understanding is, if this is
> > done, a new base/hdlist{2} file{s} is/are needed to be created. I've
> > read around a bit, and apparently I'm supposed to use a tool named
> > "genhdlist", but I've not been able to find any documentation on this
> > tool, what exactly it does, and how exactly to use it.
>
> genhdlist is part of anaconda-runtime
>
> Here is some good info:
>
> http://fedoraproject.org/wiki/Anaconda
>
> http://fedoraproject.org/wiki/AnacondaBinaries
>
> Here is all the stuff you need to run the anaconda binaries:
>
> http://fedoraproject.org/wiki/AnacondaBuildEnvironment
>
> (Although anaconda is very much undocumented)
>
> >
> > I'm expressing my frustration, along with many other people who have
> > been in the same situation, as seen from the kickstart-list.
> >
> > I guess what I'm asking for, is if someone has ever made a completely
> > custom kickstart install that does the following:
> >
> > 1) edits comps.xml to modify @base and @core
> > 2) takes newer packages into consideration
> > 3) compiles this information, creates new hdlist{2} reference files
> > 4) gets the mother to work.
> >
> > This seemingly simple process seems to lack a bit of documentation. I
> > ahve found sniplets all over the 'net where it would show a small
> > process of how to get all this done, however, the author fails to
> > document the utility or method in detail, or the process is for
> > something totally archaic such as RH6.2.
> >
> > Any help would be greatly appreciated.
>
> Here is the script I use to build the ISOs from the main tree:
>
> http://centos.hughesjr.com/testing/build.sh.txt
Here is my .rpmmacros of i386:
http://centos.hughesjr.com/testing/rpmmacros