[CentOS] Dell vostro 1550, BCM 4313 wireless, not connecting to net
Hello All, I have a Dell Vostro 1550 laptop. i3 core, 64 bit, 8gb ram etc etc. I had a nic interface, but some how the wired nic is not working. So I am trying to use the BCM 4313 wireless chip, of this system, to connect to the internet. I have Cent os 6.5 (64 bit) installed with the required libraries and kernel sources, headers etc. I got the source code of the driver, hybrid-v35_64-nodebug-pcoem-6_30_223_141.tar.gz. Extracted the tar, and compiled. Normal compilation errors: # make ## Errors # make API=CFG80211 ## Errors # make API=WEXT -> Compiles fine. # rmmod bcma echo "blacklist bcma" >> /etc/modprobe.d/blacklist.conf # modprobe lib80211 # modprobe cfg80211 # insmod wl.ko Network Manager shows all surrounding wireless network, and I select my wifi network and enter the key. Authentication required by wireless network (Dialog Box) Passwords or encryption keys are required to access the wireless network 'giri' Wireless security : WEP 40/128-bit key (HEX or ASCII) Key : * When I hit the button of this dialog box, the network manager shows the rotating signal in the network connection at the top of the Linux desktop status bar. But after a few seconds, once again this dialog-box "Authentication required by wireless network" pops up, and keeps asking me for the key/password. Rhel 6 (64 bit), I built the same driver, and make (only just make - without parameters) for compiling the driver, created the driver, without any problems. Insmod the driver, and upon selecting the wifi network and entering the key, rhel 6 64 bit version, perfectly connected to the net, on this same laptop. Can anyone let me know, why the centos 6.5 kernel/Network Manager is asking for the (wireless security) key every few seconds, again and again, and not connecting to the internet. Thanks in advance. Regards, Giri [root@localhost hybrid_wl]# [root@localhost hybrid_wl]# lspci | grep -i Broad 09:00.0 Network controller: Broadcom Corporation BCM4313 802.11bgn Wireless Network Adapter (rev 01) [root@localhost hybrid_wl]# make /root/Desktop/linux-wireless1/linux-wireless/bcm-4313/hybrid_wl/src/wl/sys/wl_cfg80211_hybrid.c:726: error: ‘struct cfg80211_ibss_params’ has no member named ‘channel’ /root/Desktop/linux-wireless1/linux-wireless/bcm-4313/hybrid_wl/src/wl/sys/wl_cfg80211_hybrid.c:1092: error: parameter 2 (‘type’) has incomplete type /root/Desktop/linux-wireless1/linux-wireless/bcm-4313/hybrid_wl/src/wl/sys/wl_cfg80211_hybrid.c:1103: error: ‘TX_POWER_AUTOMATIC’ undeclared (first use in this function) /root/Desktop/linux-wireless1/linux-wireless/bcm-4313/hybrid_wl/src/wl/sys/wl_cfg80211_hybrid.c:1103: error: (Each undeclared identifier is reported only once /root/Desktop/linux-wireless1/linux-wireless/bcm-4313/hybrid_wl/src/wl/sys/wl_cfg80211_hybrid.c:1103: error: for each function it appears in.) /root/Desktop/linux-wireless1/linux-wireless/bcm-4313/hybrid_wl/src/wl/sys/wl_cfg80211_hybrid.c:1105: error: ‘TX_POWER_LIMITED’ undeclared (first use in this function) /root/Desktop/linux-wireless1/linux-wireless/bcm-4313/hybrid_wl/src/wl/sys/wl_cfg80211_hybrid.c:: error: ‘TX_POWER_FIXED’ undeclared (first use in this function) /root/Desktop/linux-wireless1/linux-wireless/bcm-4313/hybrid_wl/src/wl/sys/wl_cfg80211_hybrid.c: At top level: /root/Desktop/linux-wireless1/linux-wireless/bcm-4313/hybrid_wl/src/wl/sys/wl_cfg80211_hybrid.c:1589: warning: initialization from incompatible pointer type /root/Desktop/linux-wireless1/linux-wireless/bcm-4313/hybrid_wl/src/wl/sys/wl_cfg80211_hybrid.c:1594: warning: initialization from incompatible pointer type /root/Desktop/linux-wireless1/linux-wireless/bcm-4313/hybrid_wl/src/wl/sys/wl_cfg80211_hybrid.c:1595: warning: initialization from incompatible pointer type /root/Desktop/linux-wireless1/linux-wireless/bcm-4313/hybrid_wl/src/wl/sys/wl_cfg80211_hybrid.c:1596: warning: initialization from incompatible pointer type /root/Desktop/linux-wireless1/linux-wireless/bcm-4313/hybrid_wl/src/wl/sys/wl_cfg80211_hybrid.c:1597: warning: initialization from incompatible pointer type /root/Desktop/linux-wireless1/linux-wireless/bcm-4313/hybrid_wl/src/wl/sys/wl_cfg80211_hybrid.c:1598: warning: initialization from incompatible pointer type /root/Desktop/linux-wireless1/linux-wireless/bcm-4313/hybrid_wl/src/wl/sys/wl_cfg80211_hybrid.c:1599: warning: initialization from incompatible pointer type /root/Desktop/linux-wireless1/linux-wireless/bcm-4313/hybrid_wl/src/wl/sys/wl_cfg80211_hybrid.c: In function ‘wl_inform_single_bss’: /root/Desktop/linux-wireless1/linux-wireless/bcm-4313/hybrid_wl/src/wl/sys/wl_cfg80211_hybrid.c:1764: error: too few arguments to function ‘ieee80211_channel_to_frequency’ /root/Desktop/linux-wireless1/linux-wireless/bcm-4313/hybrid_wl/src/wl/sys/wl_cfg80211_hybrid.c:1793: warning: passing argument 1 of ‘cfg80211_put_bss’ from incompatible
[CentOS] Seeking Speakers for Upcoming Dojos
Hi all, If you follow the centos-promo mailing list (it exists!)[1] you may have noticed a lot of discussion lately around putting together a lot of CentOS Dojos this year. We're currently planning, and have announced, several Dojos: * March 31 (Santa Clara, CA): http://wiki.centos.org/Events/Dojo/SantaClara2014 * April 10 (Denver, CO): http://wiki.centos.org/Events/Dojo/Denver2014 * April 11 (Lyon, France): http://wiki.centos.org/Events/Dojo/Lyon2014 And we have quite a few more. If you are using CentOS in production, doing interesting things on CentOS, or have ideas for presentations that would be very interesting for CentOS users, please feel free to get in touch with me or KB about speaking at one of the Dojos. We're very much looking for presentations or discussions that will be relevant to folks who are using CentOS at scale. Case studies, best practices, tips and tricks, etc. What we avoid at Dojos are product pitches or 101-type presentations that won't be useful for experienced admins / users. Please let me know if you have any questions. Thanks! [1] http://lists.centos.org/mailman/listinfo/centos-promo -- Joe Brockmeier j...@zonker.net Twitter: @jzb http://www.dissociatedpress.net/ ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] OT: missing /dev paths
On 3/12/2014 9:18 PM, Steven Tardy wrote: > rescan-scsi-bus.sh? > > https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Online_Storage_Reconfiguration_Guide/rescan-scsi-bus.html > I think I found a solution. For each incorrect disk run: echo "scsi remove-single-device 2 0 0 40" > /proc/scsi/scsi Then run: rescan-scsi-bus.sh multipath -F;multipath Thanks James ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] OT: missing /dev paths
On 3/12/2014 9:18 PM, Steven Tardy wrote: > rescan-scsi-bus.sh? > > https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Online_Storage_Reconfiguration_Guide/rescan-scsi-bus.html > So far the only thing that I found to work is to remove the path from the SAN side, then rescan, then readd, then rescan. Unfortunately there are way too may bad paths to really make that a viable option. Thanks James ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] OT: missing /dev paths
On 3/12/2014 9:18 PM, Steven Tardy wrote: > rescan-scsi-bus.sh? > > https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Online_Storage_Reconfiguration_Guide/rescan-scsi-bus.html > Tried that, as well as "rescan-scsi-bus.sh --forcerescan", as well as a "rescan-scsi-bus.sh -i" None of them make a difference. Thanks James ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] OT: missing /dev paths
rescan-scsi-bus.sh? https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Online_Storage_Reconfiguration_Guide/rescan-scsi-bus.html > On Mar 12, 2014, at 7:24 PM, James Pifer wrote: > > Looking for help kind of in a hurry. I've been searching google but not > finding any options. > > Is there any way to fix missing /dev paths to luns without rebooting? > > For example, see the output from lsscsi below. The only way I know to > fix this is with a reboot, but I REALLY Need to avoid that if possible. > > Thanks > James > > > [2:0:1:150] diskDataCore Virtual Disk DCS - > [2:0:1:151] diskDataCore Virtual Disk DCS - > [2:0:1:152] diskDataCore Virtual Disk DCS - > [2:0:1:153] diskDataCore Virtual Disk DCS - > [2:0:1:154] diskDataCore Virtual Disk DCS /dev/sdic > [2:0:1:155] diskDataCore Virtual Disk DCS - > [2:0:1:156] diskDataCore Virtual Disk DCS - > [2:0:1:157] diskDataCore Virtual Disk DCS - > [2:0:1:158] diskDataCore Virtual Disk DCS - > [2:0:1:159] diskDataCore Virtual Disk DCS /dev/sdid > [2:0:1:160] diskDataCore Virtual Disk DCS /dev/sdie > [2:0:1:161] diskDataCore Virtual Disk DCS - > [2:0:1:162] diskDataCore Virtual Disk DCS - > [2:0:1:163] diskDataCore Virtual Disk DCS - > [2:0:1:164] diskDataCore Virtual Disk DCS - > [2:0:1:165] diskDataCore Virtual Disk DCS /dev/sdif > [2:0:1:166] diskDataCore Virtual Disk DCS /dev/sdig > [2:0:1:167] diskDataCore Virtual Disk DCS /dev/sdih > [2:0:1:168] diskDataCore Virtual Disk DCS /dev/sdii > [2:0:1:169] diskDataCore Virtual Disk DCS /dev/sdij > ___ > CentOS mailing list > CentOS@centos.org > http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] OT: missing /dev paths
On Wed, Mar 12, 2014 at 7:24 PM, James Pifer wrote: > Looking for help kind of in a hurry. I've been searching google but not > finding any options. > > Is there any way to fix missing /dev paths to luns without rebooting? > > For example, see the output from lsscsi below. The only way I know to > fix this is with a reboot, but I REALLY Need to avoid that if possible. > > Thanks > James I found something the other day that might help... I used it to add new disks to a VM without a reboot. http://www.cyberciti.biz/tips/vmware-add-a-new-hard-disk-without-rebooting-guest.html echo "- - -" > /sys/class/scsi_host/host#/scan fdisk -l tail -f /var/log/message is the relevant piece. note where it says 'host#' you'll need to find the host number (all mine had 0,1,2); I can't swear this won't make your host catch on fire, burn to the ground, return as a zombie and write bad checks in your name, but it seemed to work for me. -- Even the Magic 8 ball has an opinion on email clients: Outlook not so good. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] OT: missing /dev paths
Looking for help kind of in a hurry. I've been searching google but not finding any options. Is there any way to fix missing /dev paths to luns without rebooting? For example, see the output from lsscsi below. The only way I know to fix this is with a reboot, but I REALLY Need to avoid that if possible. Thanks James [2:0:1:150] diskDataCore Virtual Disk DCS - [2:0:1:151] diskDataCore Virtual Disk DCS - [2:0:1:152] diskDataCore Virtual Disk DCS - [2:0:1:153] diskDataCore Virtual Disk DCS - [2:0:1:154] diskDataCore Virtual Disk DCS /dev/sdic [2:0:1:155] diskDataCore Virtual Disk DCS - [2:0:1:156] diskDataCore Virtual Disk DCS - [2:0:1:157] diskDataCore Virtual Disk DCS - [2:0:1:158] diskDataCore Virtual Disk DCS - [2:0:1:159] diskDataCore Virtual Disk DCS /dev/sdid [2:0:1:160] diskDataCore Virtual Disk DCS /dev/sdie [2:0:1:161] diskDataCore Virtual Disk DCS - [2:0:1:162] diskDataCore Virtual Disk DCS - [2:0:1:163] diskDataCore Virtual Disk DCS - [2:0:1:164] diskDataCore Virtual Disk DCS - [2:0:1:165] diskDataCore Virtual Disk DCS /dev/sdif [2:0:1:166] diskDataCore Virtual Disk DCS /dev/sdig [2:0:1:167] diskDataCore Virtual Disk DCS /dev/sdih [2:0:1:168] diskDataCore Virtual Disk DCS /dev/sdii [2:0:1:169] diskDataCore Virtual Disk DCS /dev/sdij ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS 5.x and HP ACU CLI
John R Pierce wrote: > On 3/12/2014 2:21 PM, m.r...@5-cent.us wrote: >> Hang on - here's something you might be interested in: I just rebuilt a >> DL380 G5 from XP Server (!) to CentOS 6.5. After I installed hpacucli, >> and >> tried to configure the attached RAID box... and*boy* was that screwed >> up. >> I have 25 drives in the RAID box. But hpacucli showed me drives in bays >> 9-17*twice*, then the rest as singletons. I rebooted, and used the >> firmware, and it reported the same thing, meaning there's crap in that >> thar code. However, I was able to configure it the way we wanted - 24 >> drives RAID 6, one hot spare, because in the firmware, it offers the >> drives with check boxes, so regardless of what where it*says* they are, >> I >> could check what I wanted, and that worked correctly. > > are you using non-HP drives? is this dual ported SAS with SAS > drives? or what? All HP, as far as I know. mark ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Disk space warning ("gdu-notification-daemon" type) for remote systems
On Wed, 2014-03-12 at 10:46 -0400, m.r...@5-cent.us wrote: > Perhaps a milter to forward a logwatch email (which goes to root) if > there's a line that has on it "Warning. Disk Filling up"? Logwatch is usually once a day, just pass midnight here. Besides disk usage is standard (no configuration required) on the Logwatches we get for C5 and C6. Its at the end. -- Paul. England, EU. Our systems are exclusively Centos. No Micro$oft Windoze here. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS 5.x and HP ACU CLI
On 3/12/2014 2:21 PM, m.r...@5-cent.us wrote: > Hang on - here's something you might be interested in: I just rebuilt a > DL380 G5 from XP Server (!) to CentOS 6.5. After I installed hpacucli, and > tried to configure the attached RAID box... and*boy* was that screwed up. > I have 25 drives in the RAID box. But hpacucli showed me drives in bays > 9-17*twice*, then the rest as singletons. I rebooted, and used the > firmware, and it reported the same thing, meaning there's crap in that > thar code. However, I was able to configure it the way we wanted - 24 > drives RAID 6, one hot spare, because in the firmware, it offers the > drives with check boxes, so regardless of what where it*says* they are, I > could check what I wanted, and that worked correctly. are you using non-HP drives? is this dual ported SAS with SAS drives? or what? -- john r pierce 37N 122W somewhere on the middle of the left coast ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS 5.x and HP ACU CLI
John R Pierce wrote: > On 3/12/2014 2:12 PM, John R Pierce wrote: >> # hpacucli ctrl all show config >> >> Error: No controllers detected. > > never mind, I installed an old version :-/ > Hang on - here's something you might be interested in: I just rebuilt a DL380 G5 from XP Server (!) to CentOS 6.5. After I installed hpacucli, and tried to configure the attached RAID box... and *boy* was that screwed up. I have 25 drives in the RAID box. But hpacucli showed me drives in bays 9-17 *twice*, then the rest as singletons. I rebooted, and used the firmware, and it reported the same thing, meaning there's crap in that thar code. However, I was able to configure it the way we wanted - 24 drives RAID 6, one hot spare, because in the firmware, it offers the drives with check boxes, so regardless of what where it *says* they are, I could check what I wanted, and that worked correctly. mark, unimpressed with HP software ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS 5.x and HP ACU CLI
On 3/12/2014 2:12 PM, John R Pierce wrote: > # hpacucli ctrl all show config > > Error: No controllers detected. never mind, I installed an old version :-/ -- john r pierce 37N 122W somewhere on the middle of the left coast ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] CentOS 5.x and HP ACU CLI
I had to install C5 on a dev server for various reasons (legacy system support and so forth).This dev server is a HP DL180 G6, with a SmartArray P410 raid card... I've installed hpacucli via the RPM from HP's site, but its not finding the controller... C5 (64 bit) is using the default CCISS drivers for this card. # hpacucli ctrl all show config Error: No controllers detected. lspci -v reports... 06:00.0 RAID bus controller: Hewlett-Packard Company Smart Array G6 controllers (rev 01) Subsystem: Hewlett-Packard Company Smart Array P410 Flags: bus master, fast devsel, latency 0, IRQ 66 Memory at fbc0 (64-bit, non-prefetchable) [size=2M] Memory at fbbff000 (64-bit, non-prefetchable) [size=4K] I/O ports at d800 [size=256] Expansion ROM at fbb0 [disabled] [size=512K] Capabilities: [40] Power Management version 3 Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [70] Express Endpoint, MSI 00 Capabilities: [ac] MSI-X: Enable+ Count=16 Masked- Capabilities: [100] Advanced Error Reporting Kernel driver in use: cciss Kernel modules: cciss -- john r pierce 37N 122W somewhere on the middle of the left coast ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Anyone using trac on centos?
Peter Brady wrote: > On 13/03/14 5:02 AM, m.r...@5-cent.us wrote: >> (Besides Paul, who's busy?) >> >> I just need one question answered: I keep reading the docs, and given >> the >> old traditional >> /var/www >> I get that part of trac should be installed in /var/www/trac/ (I >> think); what I can't figure out is whether there is *anything* under the >> document root, that is, /var/www/html/trac/. >> >> Anyone have a clue? Do I even need it as a placeholder, or does anything >> actually go in there? > > Hi Mark, > > I've got a couple of centos 6 VMs running trac and subversion. One is a > standalone single project and the other runs a multi-site install. trac > was installed from EPEL. > > For the single site install I've got a few things in /var/www/html: > > [root@develop www]# ls html/ Thanks, Peter. Between you and Paul, and, of course, much googling, I've got it working. I was completely thrown off by, basically, *NOTHING* being under the DocumentRoot. Oh, and them having htdocs *under* their non-doc-root stuff. Installing the agilo-plugin was easy (well, I'll know when my user gets going). Now shutting up selinux And no, what I found was *wrong*, it was telling you to use chcon, which does *not* last across reboots. semanage (bleah!) mark ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Anyone using trac on centos?
On 13/03/14 5:02 AM, m.r...@5-cent.us wrote: > (Besides Paul, who's busy?) > > I just need one question answered: I keep reading the docs, and given the > old traditional > /var/www > I get that part of trac should be installed in /var/www/trac/ (I > think); what I can't figure out is whether there is *anything* under the > document root, that is, /var/www/html/trac/. > > Anyone have a clue? Do I even need it as a placeholder, or does anything > actually go in there? Hi Mark, I've got a couple of centos 6 VMs running trac and subversion. One is a standalone single project and the other runs a multi-site install. trac was installed from EPEL. For the single site install I've got a few things in /var/www/html: [root@develop www]# ls html/ favicon.ico favicon.png svnindex.css svnindex.xsl [root@develop www]# But they are mainly convenience formatting for subversion browsing. Inside /var/www/trac is all the trac stuff, which was created via trac-admin. Slightly different for the multi-site install in that the folder structure has an additional level: [root@develop www]# pwd /var/www [root@develop www]# ls trac hydra mmm tuflowJobHist wma_admin [root@develop www]# In this case, trac-admin creates the projects within the sub-folders. but the contents of /var/www are the same as above. I also split out some of the static htdocs from trac to let apache cache them, so /var/www becomes: [root@develop www]# ls cgi-bin error html icons lost+found svn trac trac-static [root@develop www]# For both cases /etc/httpd/conf.d/trac.conf handles redirects, aliases, caching, cgi etc. With nothing in /var/www. Hope this helps, -pete -- Peter Brady Email: pdbr...@ans.com.au Skype: pbrady77 signature.asc Description: OpenPGP digital signature ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Anyone using trac on centos?
On Wed, Mar 12, 2014 at 1:02 PM, wrote: > (Besides Paul, who's busy?) > > I just need one question answered: I keep reading the docs, and given the > old traditional > /var/www > I get that part of trac should be installed in /var/www/trac/ (I > think); what I can't figure out is whether there is *anything* under the > document root, that is, /var/www/html/trac/. > > Anyone have a clue? Do I even need it as a placeholder, or does anything > actually go in there? Don't know anything about this specific case, but one thing that will get you is a redirect from apache if you omit the trailing / in the URL from the browser. That is, if the apache config has a handler for /trac/ but the user asks for http://server_name/trac, having that directory under your default DocumentRoot (actually probably /var/www/html/) will make apache redirect the browser to http://server_name/trac/ and make everything else work. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Anyone using trac on centos?
(Besides Paul, who's busy?) I just need one question answered: I keep reading the docs, and given the old traditional /var/www I get that part of trac should be installed in /var/www/trac/ (I think); what I can't figure out is whether there is *anything* under the document root, that is, /var/www/html/trac/. Anyone have a clue? Do I even need it as a placeholder, or does anything actually go in there? mark ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Disk space warning ("gdu-notification-daemon" type) for remote systems
Les Mikesell wrote: > On Wed, Mar 12, 2014 at 9:46 AM, wrote: >> Toralf Lund wrote: >> >>> Obviously. But like I said, I was wondering if there was a "more >>> automatic" way directly supported by the distro. Like, maybe you could >>> somehow configure "gdu-notification-daemon" so that it would >>> >>> 1. Start automatically independently of logins. >>> 2. Redirect notifications to a different system. >>> >> >> Perhaps a milter to forward a logwatch email (which goes to root) if >> there's a line that has on it "Warning. Disk Filling up"? > > I think logwatch only runs once a day. If something is being logged > you can catch it immediately with swatch. And you can send a pop-up > to an X session with 'send-notify' - with the usual assortment of ways > to connect to remote sessions (along with the usual issues of having > permission to connect to sessions that aren't yours.). It does only run once a day. I wasn't sure just how frequently a user fills the filesystem, or how much might happen in one day. I am, please note, strongly prefer fire prevention to fire-fighting. mark ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] RHEL7 beta discussions?
On Wed, Mar 12, 2014 at 5:13 AM, Karanbir Singh wrote: > an appropriate place to get help with the quirks of RHEL7 beta, particularly GUI usability issues? Gn >>> I believe this may help: >>> >>> https://access.redhat.com/site/discussions?keyword=&name=&product=All&category=All&tags=All >> >> From: https://access.redhat.com/site/discussions/443233 >> "Red Hat Customer Portal Discussions are open to the public and can be >> viewed by everyone, but you must have a Red Hat Subscription to post and >> participate." >> >> If you're just a Centos user who's trying out the RHEL7 beta, you're >> apparently outta luck. >> > > > or use this list :) If other people have the same problems, maybe some of the answers will show up in the RHEL 7 discussions anyway, But, since the problems will eventually be CentOS problems, if anyone else is trying the beta, what is the best 'remote desktop' approach (x2go in epel works, but only with KDE), what fonts do you use, and if you use kde, how do you get visible borders on your windows? -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Disk space warning ("gdu-notification-daemon" type) for remote systems
On Wed, Mar 12, 2014 at 9:46 AM, wrote: > Toralf Lund wrote: > >> Obviously. But like I said, I was wondering if there was a "more >> automatic" way directly supported by the distro. Like, maybe you could >> somehow configure "gdu-notification-daemon" so that it would >> >> 1. Start automatically independently of logins. >> 2. Redirect notifications to a different system. >> > > Perhaps a milter to forward a logwatch email (which goes to root) if > there's a line that has on it "Warning. Disk Filling up"? I think logwatch only runs once a day. If something is being logged you can catch it immediately with swatch. And you can send a pop-up to an X session with 'send-notify' - with the usual assortment of ways to connect to remote sessions (along with the usual issues of having permission to connect to sessions that aren't yours.). -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Disk space warning ("gdu-notification-daemon" type) for remote systems
On Wed, Mar 12, 2014 at 9:07 AM, Toralf Lund wrote: > >> I don't think you provided enough information for anyone to help. >> What kind of remote gui are you using? > > I wouldn't actually call it a "remote gui" - there is just an > application that communicates with a server process on a remote host, > via a custom protocol. This application has a "local" GUI. The remote > host is headless, although the machine typically has X, so you could run > processes on it with remote display. > > I actually thought most if this would be clear from how I described the > system initially. No, to me a 'remote gui' would mean a remote X session, either a full desktop or a window from an app running remotely. And either of those approaches would let you run other things. >> If it is a full remote X >> desktop session (freenx/x2go or native network) you could run anything >> you could run locally at the console because it is in fact running on >> the server side. If you are running X locally on the display machine, >> you can still run anything you want on the server machine with its >> window open on the display desktop. > Obviously. But like I said, I was wondering if there was a "more > automatic" way directly supported by the distro. Like, maybe you could > somehow configure "gdu-notification-daemon" so that it would > > 1. Start automatically independently of logins. > 2. Redirect notifications to a different system. The usual approach for things like that is to start your own instance as part of your desktop startup or login script. That way it has a way to attach to 'your' session/display. >> I think it makes sense because there are already frameworks that are >> relatively easy to install and set up even if you initially only >> target one host and test - and you can get things like CPU and network >> bandwidth tracking for free. > Maybe. > > However, I should perhaps also add that anything based on notification > based on e-mail or similar services might lead to problems in that the > systems don't normally deliver or receive e-mails. Mail is sort of server-centric. That is, sending/receiving are pretty lightweight with any number of easily available tools, and you probably already have (or have access to) a central or public mail service. >>Then if you want, you can expand the >> monitoring to other things you are likely to need, but even if you >> don't it is probably easier than building your own notification >> system.It's probably not the easiest thing to start with, but >> OpenNMS is pretty flexible. For example if you have an xmpp system >> with clients for instant messaging, it can send alerts to a group >> conference so the interested people see it without cluttering email. > Hmm... Not sure if xmpp would be any better than email... It's the same server-centric concept, just a different approach to connecting. If you start from scratch you could run OpenFire which will archive as much as you want of the group conference so when you connect you'd see any recent issues - and like email, you can probably find a client that will run minimized and pop up a notification when a new message appears. The group-chat - or email to a group list have the feature that the person who is going to work on the problem has an easy way to tell the others with a simple reply. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Disk space warning ("gdu-notification-daemon" type) for remote systems
Toralf Lund wrote: > Obviously. But like I said, I was wondering if there was a "more > automatic" way directly supported by the distro. Like, maybe you could > somehow configure "gdu-notification-daemon" so that it would > > 1. Start automatically independently of logins. > 2. Redirect notifications to a different system. > Perhaps a milter to forward a logwatch email (which goes to root) if there's a line that has on it "Warning. Disk Filling up"? mark ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] How do graphical admin tools requiring root get authentication?
Hi All, I have created a CentOS 6.5 OpenStack image using kickstart. I have noticed that when connecting directly to the Virtual Machine's console (think connecting directly to the physical machine) all of the system-config, firewall configuration, application update and install GUI applications work fine and prompt for root login when executed. Hoever if I connect to the VM using xrdp with a tiger-vncserver backend the apps either do not work, or take several minutes to prompt for the root password. Here is a post I made in the forums that has no response: https://www.centos.org/forums/viewtopic.php?f=13&t=45307&sid=865afae345fe831c86661f5f264f9021 It looks like my problem may be that when I do a ck-list-sessions the device/terminal information does not seem to be known: Session2: unix-user = '500' realname = '(null)' seat = 'Seat2' session-type = '' active = FALSE x11-display = '' x11-display-device = '' display-device = '' remote-host-name = '' is-local = TRUE on-since = '2014-03-06T17:23:07.718097Z' login-session-id = '4294967295' I have tried disabling selinux, modifying the startwm.sh script included with xrdp to launch the session with "ck-launch-session gnome-session". Neither seem to help. Does anyone have any idea what might be going, or an explanation of how authentication works when one of these apps requires root permission? Thanks! Sam ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Disk space warning ("gdu-notification-daemon" type) for remote systems
On 12/03/14 13:56, Les Mikesell wrote: > On Wed, Mar 12, 2014 at 4:07 AM, Toralf Lund wrote: In general, that might make sense, but please consider the fact that I'm not talking about a "general" server system. It's a machine dedicated to running a "server" component on one specific software package, and will only ever be contacted by a handful of "display" machines running a GUI component of the same piece of software. >>> Then you need to look at the features of the specific GUI and its >>> transport to the server to see what options it provides for popup >>> messages. >> I can easily add a check to software itself. But like I said, I want to >> avoid re-inventing the wheel. So if there is something built into the >> system that will do the job for me... > I don't think you provided enough information for anyone to help. > What kind of remote gui are you using? I wouldn't actually call it a "remote gui" - there is just an application that communicates with a server process on a remote host, via a custom protocol. This application has a "local" GUI. The remote host is headless, although the machine typically has X, so you could run processes on it with remote display. I actually thought most if this would be clear from how I described the system initially. > If it is a full remote X > desktop session (freenx/x2go or native network) you could run anything > you could run locally at the console because it is in fact running on > the server side. If you are running X locally on the display machine, > you can still run anything you want on the server machine with its > window open on the display desktop. Obviously. But like I said, I was wondering if there was a "more automatic" way directly supported by the distro. Like, maybe you could somehow configure "gdu-notification-daemon" so that it would 1. Start automatically independently of logins. 2. Redirect notifications to a different system. >>> Personally, I'd still recommend something more general >>> that would generate email or text message alerts to the right set of >>> people. It is fairly rare for 'users' to be interested in fixing >>> system problems and even if that happens to be the case now for this >>> particular box it may not always be. >> Trust me, this is a highly customised setup with very special users, and >> this won't change just like that. >> >> A more general system is not an entirely bad idea, but I think it would >> only make sense if implemented at a larger scale based on a system-wide >> policy (there is much else going on in the same network.) Which I'm not >> sure will happen right now... > I think it makes sense because there are already frameworks that are > relatively easy to install and set up even if you initially only > target one host and test - and you can get things like CPU and network > bandwidth tracking for free. Maybe. However, I should perhaps also add that anything based on notification based on e-mail or similar services might lead to problems in that the systems don't normally deliver or receive e-mails. >Then if you want, you can expand the > monitoring to other things you are likely to need, but even if you > don't it is probably easier than building your own notification > system.It's probably not the easiest thing to start with, but > OpenNMS is pretty flexible. For example if you have an xmpp system > with clients for instant messaging, it can send alerts to a group > conference so the interested people see it without cluttering email. Hmm... Not sure if xmpp would be any better than email... - Toralf > This e-mail, including any attachments and response string, may contain proprietary information which is confidential and may be legally privileged. It is for the intended recipient only. If you are not the intended recipient or transmission error has misdirected this e-mail, please notify the author by return e-mail and delete this message and any attachment immediately. If you are not the intended recipient you must not use, disclose, distribute, forward, copy, print or rely on this e-mail in any way except as permitted by the author. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Disk space warning ("gdu-notification-daemon" type) for remote systems
On Wed, Mar 12, 2014 at 4:07 AM, Toralf Lund wrote: > >>> In general, that might make sense, but please consider the fact that I'm >>> not talking about a "general" server system. It's a machine dedicated to >>> running a "server" component on one specific software package, and will >>> only ever be contacted by a handful of "display" machines running a GUI >>> component of the same piece of software. >> Then you need to look at the features of the specific GUI and its >> transport to the server to see what options it provides for popup >> messages. > I can easily add a check to software itself. But like I said, I want to > avoid re-inventing the wheel. So if there is something built into the > system that will do the job for me... I don't think you provided enough information for anyone to help. What kind of remote gui are you using? If it is a full remote X desktop session (freenx/x2go or native network) you could run anything you could run locally at the console because it is in fact running on the server side. If you are running X locally on the display machine, you can still run anything you want on the server machine with its window open on the display desktop. >> Personally, I'd still recommend something more general >> that would generate email or text message alerts to the right set of >> people. It is fairly rare for 'users' to be interested in fixing >> system problems and even if that happens to be the case now for this >> particular box it may not always be. > Trust me, this is a highly customised setup with very special users, and > this won't change just like that. > > A more general system is not an entirely bad idea, but I think it would > only make sense if implemented at a larger scale based on a system-wide > policy (there is much else going on in the same network.) Which I'm not > sure will happen right now... I think it makes sense because there are already frameworks that are relatively easy to install and set up even if you initially only target one host and test - and you can get things like CPU and network bandwidth tracking for free. Then if you want, you can expand the monitoring to other things you are likely to need, but even if you don't it is probably easier than building your own notification system.It's probably not the easiest thing to start with, but OpenNMS is pretty flexible. For example if you have an xmpp system with clients for instant messaging, it can send alerts to a group conference so the interested people see it without cluttering email. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Disk space warning ("gdu-notification-daemon" type) for remote systems
On 12/03/2014 09:07, Toralf Lund wrote: > On 11/03/14 16:16, Les Mikesell wrote: >> On Tue, Mar 11, 2014 at 9:49 AM, Toralf Lund wrote: I think you should build a monitoring system (nagios, xymon, opennms, several others or perhaps your own if you're feeling far too adventurous) instead. right now all you care about is disk space, but eventually someone will want to also check for certain processes, open ports, logfile entries, something and you could spend the time now to put in the hooks for more advanced things and get people in the habit of checking a monitoring system on a regular basis. >>> In general, that might make sense, but please consider the fact that I'm >>> not talking about a "general" server system. It's a machine dedicated to >>> running a "server" component on one specific software package, and will >>> only ever be contacted by a handful of "display" machines running a GUI >>> component of the same piece of software. >> Then you need to look at the features of the specific GUI and its >> transport to the server to see what options it provides for popup >> messages. > I can easily add a check to software itself. But like I said, I want to > avoid re-inventing the wheel. So if there is something built into the > system that will do the job for me... > >> Personally, I'd still recommend something more general >> that would generate email or text message alerts to the right set of >> people. It is fairly rare for 'users' to be interested in fixing >> system problems and even if that happens to be the case now for this >> particular box it may not always be. > Trust me, this is a highly customised setup with very special users, and > this won't change just like that. > > A more general system is not an entirely bad idea, but I think it would > only make sense if implemented at a larger scale based on a system-wide > policy (there is much else going on in the same network.) Which I'm not > sure will happen right now... > > - Toralf > > >> > > You could use the Nagios check_disk plugin to monitor the disk usage. This gives easy to use response codes and could be wrapped in a script that sends an email if if runs low on space. put in cron to run every 10 minutes or something like that and it will do what you are looking for. You can get the plugin from epel and it is trivial to install and use. Tris * This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify postmas...@bgfl.org The views expressed within this email are those of the individual, and not necessarily those of the organisation * ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] CentOS-announce Digest, Vol 109, Issue 5
Send CentOS-announce mailing list submissions to
centos-annou...@centos.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.centos.org/mailman/listinfo/centos-announce
or, via email, send a message with subject or body 'help' to
centos-announce-requ...@centos.org
You can reach the person managing the list at
centos-announce-ow...@centos.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of CentOS-announce digest..."
Today's Topics:
1. CEBA-2014:0281 CentOS 6 ksh Update (Johnny Hughes)
2. CEBA-2014:0282 CentOS 5 cman Update (Johnny Hughes)
--
Message: 1
Date: Tue, 11 Mar 2014 14:16:26 +
From: Johnny Hughes
Subject: [CentOS-announce] CEBA-2014:0281 CentOS 6 ksh Update
To: centos-annou...@centos.org
Message-ID: <20140311141626.ga47...@n04.lon1.karan.org>
Content-Type: text/plain; charset=us-ascii
CentOS Errata and Bugfix Advisory 2014:0281
Upstream details at : https://rhn.redhat.com/errata/RHBA-2014-0281.html
The following updated files have been uploaded and are currently
syncing to the mirrors: ( sha256sum Filename )
i386:
8b07c3a67e834eb488b902ec77ecdc93c03307d36dd842a6b06eaf20abdfe9ad
ksh-20120801-10.el6_5.4.i686.rpm
x86_64:
a903b3de866f36988c9b990890d748b221e424a454529d51fe69bb51de8aba36
ksh-20120801-10.el6_5.4.x86_64.rpm
Source:
6ec92478cecc44e533b42137aecfbaf2998fbcd8a4724a623e87ca97e1bafd64
ksh-20120801-10.el6_5.4.src.rpm
--
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net
--
Message: 2
Date: Tue, 11 Mar 2014 16:59:24 +
From: Johnny Hughes
Subject: [CentOS-announce] CEBA-2014:0282 CentOS 5 cman Update
To: centos-annou...@centos.org
Message-ID: <20140311165924.ga11...@chakra.karan.org>
Content-Type: text/plain; charset=us-ascii
CentOS Errata and Bugfix Advisory 2014:0282
Upstream details at : https://rhn.redhat.com/errata/RHBA-2014-0282.html
The following updated files have been uploaded and are currently
syncing to the mirrors: ( sha256sum Filename )
i386:
6b85ee4969be5a12c0b67656f15672aaf0f4132e4667a326697856cac270aa84
cman-2.0.115-118.el5_10.4.i386.rpm
6aa49110aafcbd62a15a10e1bc768fec76adc4a27d9a87e84dd08c7be2446304
cman-devel-2.0.115-118.el5_10.4.i386.rpm
x86_64:
686bd324ee9bcb82b2ecdd9b961751e5c4edad983506185b81b6b57cd50e451a
cman-2.0.115-118.el5_10.4.x86_64.rpm
6aa49110aafcbd62a15a10e1bc768fec76adc4a27d9a87e84dd08c7be2446304
cman-devel-2.0.115-118.el5_10.4.i386.rpm
3587fa2a83907928143cb31146e381bcc4a859a3d4315b05ddda9eb561323706
cman-devel-2.0.115-118.el5_10.4.x86_64.rpm
Source:
78ef1052ecab5c2f0939cd541c73d670862ca33eb262624d8b97588ba68302b1
cman-2.0.115-118.el5_10.4.src.rpm
--
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net
--
___
CentOS-announce mailing list
centos-annou...@centos.org
http://lists.centos.org/mailman/listinfo/centos-announce
End of CentOS-announce Digest, Vol 109, Issue 5
***
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
[CentOS] Desktop behaviour - click to raise
My C5, default Gnome desktop has recently changed behaviour, and I can't figure out how to restore the previous behaviour. Previously, clicking anywhere into a window raised it. Now, for the past few days, only clicking title bar or borders raises them. I logged off, completely wiped all destop settings, i.e. a whole bunch of .gnome* .gconf* .metacity etc. directories, even restarted X, and logged on again. No change. /apps/metacity/general/raise_on_click is enabled. The most baffling aspect is that click to raise works exactly as expected in vnc sessions. Any clues how to pursue this? Am I imagining it because my Linux desktop at home does click to raise? :) ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] RHEL7 beta discussions?
On 03/11/2014 11:46 PM, Frank Cox wrote: > On Tue, 11 Mar 2014 16:38:52 -0700 > Edward M wrote: > >> On 3/11/2014 8:45 AM, Les Mikesell wrote: >>> an appropriate place to get help with the quirks of >>> RHEL7 beta, particularly GUI usability issues? Gn >> I believe this may help: >> >> https://access.redhat.com/site/discussions?keyword=&name=&product=All&category=All&tags=All > > From: https://access.redhat.com/site/discussions/443233 > "Red Hat Customer Portal Discussions are open to the public and can be viewed > by everyone, but you must have a Red Hat Subscription to post and > participate." > > If you're just a Centos user who's trying out the RHEL7 beta, you're > apparently outta luck. > or use this list :) -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Disk space warning ("gdu-notification-daemon" type) for remote systems
On 11/03/14 16:16, Les Mikesell wrote: > On Tue, Mar 11, 2014 at 9:49 AM, Toralf Lund wrote: >>> I think you should build a >>> monitoring system (nagios, xymon, opennms, several others or perhaps >>> your own if you're feeling far too adventurous) instead. right now >>> all you care about is disk space, but eventually someone will want to >>> also check for certain processes, open ports, logfile entries, >>> something and you could spend the time now to put in the hooks for >>> more advanced things and get people in the habit of checking a >>> monitoring system on a regular basis. >> In general, that might make sense, but please consider the fact that I'm >> not talking about a "general" server system. It's a machine dedicated to >> running a "server" component on one specific software package, and will >> only ever be contacted by a handful of "display" machines running a GUI >> component of the same piece of software. > Then you need to look at the features of the specific GUI and its > transport to the server to see what options it provides for popup > messages. I can easily add a check to software itself. But like I said, I want to avoid re-inventing the wheel. So if there is something built into the system that will do the job for me... > Personally, I'd still recommend something more general > that would generate email or text message alerts to the right set of > people. It is fairly rare for 'users' to be interested in fixing > system problems and even if that happens to be the case now for this > particular box it may not always be. Trust me, this is a highly customised setup with very special users, and this won't change just like that. A more general system is not an entirely bad idea, but I think it would only make sense if implemented at a larger scale based on a system-wide policy (there is much else going on in the same network.) Which I'm not sure will happen right now... - Toralf > This e-mail, including any attachments and response string, may contain proprietary information which is confidential and may be legally privileged. It is for the intended recipient only. If you are not the intended recipient or transmission error has misdirected this e-mail, please notify the author by return e-mail and delete this message and any attachment immediately. If you are not the intended recipient you must not use, disclose, distribute, forward, copy, print or rely on this e-mail in any way except as permitted by the author. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
