[OT] Sendmail: Open relay was tested as closed but...
by Dan Thurman
for some reason, spammers are getting through TLS
and are bypassing/ignoring access database? I poured
over the Internet but have yet to figure it out...
How can I prevent spammers from using my sendmail
server as an open relay even though open-relay is closed?
Note STARTTLS=client and deferred deliveries when
mail delivery fails and returns errors to my email server?
/var/log/maillog small sample reveals:
Apr 20 11:26:33 <MYEMAILSERVER> sendmail[1817]: STARTTLS=client,
relay=gmail-smtp-in.l.google.com., version=TLSv1/SSLv3, verify=OK,
cipher=ECDHE-RSA-AES128-GCM-SHA256, bits=128/128
Apr 20 11:26:36 <MYEMAILSERVER> sendmail[1817]: STARTTLS=client,
relay=alt1.gmail-smtp-in.l.google.com., version=TLSv1/SSLv3, verify=OK,
cipher=ECDHE-RSA-AES128-GCM-SHA256, bits=128/128
Apr 20 11:26:37 <MYEMAILSERVER> sendmail[1817]: STARTTLS=client,
relay=alt2.gmail-smtp-in.l.google.com., version=TLSv1/SSLv3, verify=OK,
cipher=ECDHE-RSA-AES128-GCM-SHA256, bits=128/128
Apr 20 11:26:39 <MYEMAILSERVER> sendmail[1817]: STARTTLS=client,
relay=alt3.gmail-smtp-in.l.google.com., version=TLSv1/SSLv3, verify=OK,
cipher=ECDHE-RSA-AES128-GCM-SHA256, bits=128/128
Apr 20 11:26:41 <MYEMAILSERVER> sendmail[1817]: STARTTLS=client,
relay=alt4.gmail-smtp-in.l.google.com., version=TLSv1/SSLv3, verify=OK,
cipher=ECDHE-RSA-AES128-GCM-SHA256, bits=128/128
Apr 20 11:26:42 <MYEMAILSERVER> sendmail[1817]: s3K1ceVt003083:
to=<kshitijbansal23(a)gmail.com>,<luke.m.armstrong(a)gmail.com>,<mercedesyardley(a)gmail.com>,<misti.wolanski(a)gmail.com>,<mzlangston(a)gmail.com>,<rat.latin.org(a)gmail.com>,<richardthepoet(a)gmail.com>,<rohith003(a)gmail.com>,<treycooper(a)gmail.com>,
delay=16:47:57, xdelay=00:00:09, mailer=esmtp, pri=77257,
relay=alt4.gmail-smtp-in.l.google.com. [173.194.75.26], dsn=4.0.0,
stat=Deferred: 421-4.7.0 [50.126.86.236 15] Our system has detected
an unusual rate of
Apr 20 11:26:42 <MYEMAILSERVER> sendmail[1817]: s3K4nDlG014204:
to=<akang488(a)gmail.com>,<kevin.mckinn(a)gmail.com>,<mmaness(a)gmail.com>,<nflagola(a)gmail.com>,
delay=13:37:14, xdelay=00:00:00, mailer=esmtp, pri=67111,
relay=alt4.gmail-smtp-in.l.google.com., dsn=4.0.0, stat=Deferred
Apr 20 11:26:43 <MYEMAILSERVER> sendmail[1817]: STARTTLS=client,
relay=aspmx.l.google.com., version=TLSv1/SSLv3, verify=OK,
cipher=ECDHE-RSA-AES128-GCM-SHA256, bits=128/128
Apr 20 11:26:45 <MYEMAILSERVER> sendmail[1817]: STARTTLS=client,
relay=alt1.aspmx.l.google.com., version=TLSv1/SSLv3, verify=OK,
cipher=ECDHE-RSA-AES128-GCM-SHA256, bits=128/128
Apr 20 11:26:46 <MYEMAILSERVER> sendmail[1817]: STARTTLS=client,
relay=alt2.aspmx.l.google.com., version=TLSv1/SSLv3, verify=OK,
cipher=ECDHE-RSA-AES128-GCM-SHA256, bits=128/128
Apr 20 11:26:47 <MYEMAILSERVER> sendmail[1817]: STARTTLS=client,
relay=aspmx2.googlemail.com., version=TLSv1/SSLv3, verify=OK,
cipher=ECDHE-RSA-AES128-GCM-SHA256, bits=128/128
Apr 20 11:26:48 <MYEMAILSERVER> sendmail[1817]: STARTTLS=client,
relay=aspmx3.googlemail.com., version=TLSv1/SSLv3, verify=OK,
cipher=ECDHE-RSA-AES128-GCM-SHA256, bits=128/128
Apr 20 11:26:49 <MYEMAILSERVER> sendmail[1817]: s3K4nDlK014204:
to=<announcements(a)bariatricadvantage.com>, delay=13:36:45,
xdelay=00:00:06, mailer=esmtp, pri=64282, relay=aspmx3.googlemail.com.
[74.125.196.26], dsn=4.0.0, stat=Deferred: 421-4.7.0 [50.126.86.236
15] Our system has detected an unusual rate of
Apr 20 11:26:49 <MYEMAILSERVER> sendmail[1817]: s3K4nDlK014204:
to=<redbarn.kennedy(a)gmail.com>, delay=13:36:45, xdelay=00:00:00,
mailer=esmtp, pri=64282, relay=alt4.gmail-smtp-in.l.google.com.,
dsn=4.0.0, stat=Deferred
Apr 20 11:26:52 <MYEMAILSERVER> sendmail[1817]: s3K51Tx3015146:
to=<leah(a)pasafarming.org>,<bphouben(a)pennswoods.net>,<leveson(a)netsync.net>,
delay=13:25:18, xdelay=00:00:00, mailer=esmtp, pri=66225,
relay=aspmx2.googlemail.com., dsn=4.0.0, stat=Deferred
Apr 20 11:26:52 <MYEMAILSERVER> sendmail[1817]: s3K51Tx3015146:
to=<leah(a)pasafarming.org>, delay=13:25:18, xdelay=00:00:00,
mailer=esmtp, pri=66225, relay=aspmx3.googlemail.com., dsn=4.0.0,
stat=Deferred
Apr 20 11:26:52 <MYEMAILSERVER> sendmail[1817]: s3K51Tx3015146:
to=<bethrosler(a)gmail.com>,<delphine67(a)gmail.com>, delay=13:25:18,
xdelay=00:00:00, mailer=esmtp, pri=66225,
relay=alt4.gmail-smtp-in.l.google.com., dsn=4.0.0, stat=Deferred
Apr 20 11:26:55 <MYEMAILSERVER> sendmail[1817]: s3K51Tx5015146:
to=<DMankowski(a)us.com>,<lisa(a)cmmpr.com>, delay=13:24:48,
xdelay=00:00:00, mailer=esmtp, pri=68195, relay=aspmx3.googlemail.com.,
dsn=4.0.0, stat=Deferred
Apr 20 11:26:56 <MYEMAILSERVER> sendmail[1817]: STARTTLS=client,
relay=aspmx5.googlemail.com., version=TLSv1/SSLv3, verify=OK,
cipher=ECDHE-RSA-AES128-GCM-SHA256, bits=128/128
Apr 20 11:26:58 <MYEMAILSERVER> sendmail[1817]: STARTTLS=client,
relay=aspmx4.googlemail.com., version=TLSv1/SSLv3, verify=OK,
cipher=ECDHE-RSA-AES128-GCM-SHA256, bits=128/128
Apr 20 11:26:59 <MYEMAILSERVER> sendmail[1817]: s3K51Tx5015146:
to=<DMankowski(a)us.com>, delay=13:24:52, xdelay=00:00:04, mailer=esmtp,
pri=68195, relay=aspmx4.googlemail.com. [74.125.29.26], dsn=4.0.0,
stat=Deferred: 421-4.7.0 [50.126.86.236 15] Our system has detected
an unusual rate of
Apr 20 11:27:00 <MYEMAILSERVER> sendmail[1817]: s3K51Tx8015146:
to=<verify(a)relay05.reunion.com>, delay=13:23:54, xdelay=00:00:01,
mailer=esmtp, pri=60863, relay=relay05.reunion.com. [216.52.223.215],
dsn=4.0.0, stat=Deferred: Connection refused by relay05.reunion.com.
Apr 20 11:27:00 <MYEMAILSERVER> sendmail[1817]: s3K7IrL5023404:
to=<susan.creager(a)gmail.com>, delay=11:07:25, xdelay=00:00:00,
mailer=esmtp, pri=60276, relay=alt4.gmail-smtp-in.l.google.com.,
dsn=4.0.0, stat=Deferred
Apr 20 11:28:02 <MYEMAILSERVER> dovecot: imap(dant): Disconnected:
Logged out in=123 out=611
Apr 20 11:28:39 <MYEMAILSERVER> sendmail[2019]: starting daemon
(8.14.7): SMTP+queueing@01:00:00
Apr 20 11:28:40 <MYEMAILSERVER> sm-msp-queue[2035]: starting daemon
(8.14.7): queueing@01:00:00
Apr 20 11:42:46 <MYEMAILSERVER> sendmail[3038]: AUTH=server,
relay=90.148.226.111.dynamic.saudi.net.sa [90.148.226.111] (may be
forged), authid=kimt(a)cdkkt.com, mech=PLAIN, bits=0
Apr 20 11:43:49 <MYEMAILSERVER> sendmail[3038]: s3KIgjev003038: lost
input channel from 90.148.226.111.dynamic.saudi.net.sa [90.148.226.111]
(may be forged) to MTA after rcpt
Apr 20 11:43:49 <MYEMAILSERVER> sendmail[3038]: s3KIgjev003038:
from=<slugs61(a)aol.com>, size=0, class=0, nrcpts=5, proto=ESMTP,
daemon=MTA, relay=90.148.226.111.dynamic.saudi.net.sa [90.148.226.111]
(may be forged)
Apr 20 12:01:32 <MYEMAILSERVER> sendmail[4258]: s3KJ1U19004258:
ruleset=check_rcpt, arg1=<4a0770cb.90406(a)cdkkt.com>,
relay=[58.217.76.110], reject=553 5.3.0 <4a0770cb.90406(a)cdkkt.com>...
Rejected [58.217.76.110] by barracudacentral.org
Apr 20 12:01:33 <MYEMAILSERVER> sendmail[4258]: s3KJ1U19004258: lost
input channel from [58.217.76.110] to MTA after rcpt
Apr 20 12:01:33 <MYEMAILSERVER> sendmail[4258]: s3KJ1U19004258:
from=<neogjutj(a)qzwrw.net>, size=0, class=0, nrcpts=0, proto=ESMTP,
daemon=MTA, relay=[58.217.76.110]
Apr 20 12:01:36 <MYEMAILSERVER> sendmail[4259]: s3KJ1Z2O004259:
ruleset=check_rcpt, arg1=<4a076efa.3000309(a)cdkkt.com>,
relay=[58.217.76.110], reject=553 5.3.0 <4a076efa.3000309(a)cdkkt.com>...
Rejected [58.217.76.110] by barracudacentral.org
Apr 20 12:01:37 <MYEMAILSERVER> sendmail[4259]: s3KJ1Z2O004259: lost
input channel from [58.217.76.110] to MTA after rcpt
Apr 20 12:01:37 <MYEMAILSERVER> sendmail[4259]: s3KJ1Z2O004259:
from=<zwryzrli(a)crzkl.net>, size=0, class=0, nrcpts=0, proto=ESMTP,
daemon=MTA, relay=[58.217.76.110]
Apr 20 12:01:48 <MYEMAILSERVER> sendmail[4281]: s3KJ1mq4004281:
[58.217.76.110] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
Apr 20 12:03:46 <MYEMAILSERVER> sendmail[4360]: s3KJ3FVJ004360:
[41.142.58.109] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
9 years, 12 months
grub2-install ??
by Mickey
fedora 20
I installed Fedora 20 on /dev/sdb1 and after installation was completed
it didn't select /dev/sdb1 and bootup .
I have Windows on sda1 so i put a sdb in computer for Linux.
Is the command, grub2-install /dev/sdb1 the correct command for booting
Fedora 20 on sdb1 ?
9 years, 12 months
640x480 only res available after f14 - f20 upgrade?
by Morgan Read
Hello Folks
I've upgraded a server to f20 that was running f14. There was no issue
with screen geometry/ resolution in f14, but now the only resolution
available via gnome is 640x480. That makes the machine virtually
impossible to use in a graphic environment.
I've followed these links here:
*
https://ask.fedoraproject.org/en/question/8301/how-do-i-change-my-monitor...
* https://wiki.archlinux.org/index.php/Xrandr#Adding_undetected_resolutions
* http://fedoraforum.org/forum/showthread.php?p=1584620
But, all to no avail...
I'd really appreciate anybody pointing me in the right direction(s) - I
suspect I've just not done something really straight forward as it seems
very strange that this old HP ProLiant ML 150 and equally old Dell
1703FP monitor combo which worked fine under f14 now doesn't under f20.
Here's some info from the Xorg log, from my 'no knowledge' assessment,
perhaps:
[ 22.239] (II) modesetting(0): Output VGA-0 using initial mode
640x480 +0+0
Is the most meaningful line?
Many thanks,
Morgan.
[ 21.028]
X.Org X Server 1.14.4
Release Date: 2013-10-31
[ 21.028] X Protocol Version 11, Revision 0
[ 21.028] Build Operating System: 3.12.8-300.fc20.x86_64
[ 21.028] Current Operating System: Linux localhost.localdomain
3.13.5-200.fc20.x86_64 #1 SMP Mon Feb 24 16:51:35 UTC 2014 x86_64
[ 21.028] Kernel command line:
BOOT_IMAGE=/vmlinuz-3.13.5-200.fc20.x86_64
root=/dev/mapper/VG_System-lv_root ro rd.lvm.lv=VG_System/lv_swap
vconsole.font=latarcyrheb-sun16 video=1280x1024
rd.lvm.lv=VG_System/lv_root rhgb quiet LANG=en_US.UTF-8
[ 21.029] Build Date: 04 February 2014 10:57:37PM
[ 21.029] Build ID: xorg-x11-server 1.14.4-6.fc20
[ 21.029] Current version of pixman: 0.30.0
[ 21.029] Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[ 21.029] Markers: (--) probed, (**) from config file, (==) default
setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[ 21.029] (==) Log file: "/var/log/Xorg.0.log", Time: Sat Mar 1
23:05:53 2014
[ 21.435] (==) Using config directory: "/etc/X11/xorg.conf.d"
[ 21.435] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[ 21.578] (==) No Layout section. Using the first Screen section.
[ 21.578] (==) No screen section available. Using defaults.
[ 21.578] (**) |-->Screen "Default Screen Section" (0)
[ 21.578] (**) | |-->Monitor "<default monitor>"
[ 21.850] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[ 21.850] (==) Automatically adding devices
[ 21.850] (==) Automatically enabling devices
[ 21.850] (==) Automatically adding GPU devices
[ 21.850] (==) FontPath set to:
catalogue:/etc/X11/fontpath.d,
built-ins
[ 21.850] (==) ModulePath set to "/usr/lib64/xorg/modules"
[ 21.850] (II) The server relies on udev to provide the list of input
devices.
If no devices become available, reconfigure udev or disable AutoAddDevices.
[ 21.850] (II) Loader magic: 0x80dd00
[ 21.850] (II) Module ABI versions:
[ 21.850] X.Org ANSI C Emulation: 0.4
[ 21.850] X.Org Video Driver: 14.1
[ 21.850] X.Org XInput driver : 19.2
[ 21.850] X.Org Server Extension : 7.0
[ 21.850] (II) xfree86: Adding drm device (/dev/dri/card0)
[ 21.854] (--) PCI: (0:4:2:0) 14f1:8800:0070:9202 rev 5, Mem @
0xd9000000/16777216, BIOS @ 0x????????/65536
[ 21.854] (--) PCI:*(0:7:2:0) 102b:0522:103c:31fa rev 2, Mem @
0xde000000/16777216, 0xdd810000/16384, 0xdd000000/8388608, BIOS @
0x????????/65536
[ 21.854] Initializing built-in extension Generic Event Extension
[ 21.854] Initializing built-in extension SHAPE
[ 21.854] Initializing built-in extension MIT-SHM
[ 21.854] Initializing built-in extension XInputExtension
[ 21.854] Initializing built-in extension XTEST
[ 21.854] Initializing built-in extension BIG-REQUESTS
[ 21.854] Initializing built-in extension SYNC
[ 21.854] Initializing built-in extension XKEYBOARD
[ 21.854] Initializing built-in extension XC-MISC
[ 21.854] Initializing built-in extension XINERAMA
[ 21.854] Initializing built-in extension XFIXES
[ 21.854] Initializing built-in extension RENDER
[ 21.854] Initializing built-in extension RANDR
[ 21.854] Initializing built-in extension COMPOSITE
[ 21.854] Initializing built-in extension DAMAGE
[ 21.854] Initializing built-in extension MIT-SCREEN-SAVER
[ 21.854] Initializing built-in extension DOUBLE-BUFFER
[ 21.854] Initializing built-in extension RECORD
[ 21.854] Initializing built-in extension DPMS
[ 21.854] Initializing built-in extension X-Resource
[ 21.854] Initializing built-in extension XVideo
[ 21.854] Initializing built-in extension XVideo-MotionCompensation
[ 21.854] Initializing built-in extension SELinux
[ 21.855] Initializing built-in extension XFree86-VidModeExtension
[ 21.855] Initializing built-in extension XFree86-DGA
[ 21.855] Initializing built-in extension XFree86-DRI
[ 21.855] Initializing built-in extension DRI2
[ 21.855] (II) "glx" will be loaded by default.
[ 21.855] (WW) "xwayland" is not to be loaded by default. Skipping.
[ 21.855] (II) LoadModule: "dri2"
[ 21.855] (II) Module "dri2" already built-in
[ 21.855] (II) LoadModule: "glamoregl"
[ 21.855] (II) Loading /usr/lib64/xorg/modules/libglamoregl.so
[ 21.858] (II) Module glamoregl: vendor="X.Org Foundation"
[ 21.858] compiled for 1.14.4, module version = 0.5.1
[ 21.859] ABI class: X.Org ANSI C Emulation, version 0.4
[ 21.859] (II) LoadModule: "glx"
[ 22.167] (II) Loading /usr/lib64/xorg/modules/extensions/libglx.so
[ 22.168] (II) Module glx: vendor="X.Org Foundation"
[ 22.168] compiled for 1.14.4, module version = 1.0.0
[ 22.168] ABI class: X.Org Server Extension, version 7.0
[ 22.168] (==) AIGLX enabled
[ 22.168] Loading extension GLX
[ 22.168] (==) Matched mga as autoconfigured driver 0
[ 22.168] (==) Matched mga as autoconfigured driver 1
[ 22.168] (==) Matched modesetting as autoconfigured driver 2
[ 22.168] (==) Matched fbdev as autoconfigured driver 3
[ 22.168] (==) Matched vesa as autoconfigured driver 4
[ 22.168] (==) Assigned the driver to the xf86ConfigLayout
[ 22.168] (II) LoadModule: "mga"
[ 22.168] (II) Loading /usr/lib64/xorg/modules/drivers/mga_drv.so
[ 22.168] (II) Module mga: vendor="X.Org Foundation"
[ 22.168] compiled for 1.14.2, module version = 1.6.2
[ 22.168] Module class: X.Org Video Driver
[ 22.168] ABI class: X.Org Video Driver, version 14.1
[ 22.168] (II) LoadModule: "modesetting"
[ 22.168] (II) Loading /usr/lib64/xorg/modules/drivers/modesetting_drv.so
[ 22.168] (II) Module modesetting: vendor="X.Org Foundation"
[ 22.169] compiled for 1.14.2, module version = 0.8.0
[ 22.169] Module class: X.Org Video Driver
[ 22.169] ABI class: X.Org Video Driver, version 14.1
[ 22.169] (II) LoadModule: "fbdev"
[ 22.169] (II) Loading /usr/lib64/xorg/modules/drivers/fbdev_drv.so
[ 22.169] (II) Module fbdev: vendor="X.Org Foundation"
[ 22.169] compiled for 1.14.2, module version = 0.4.3
[ 22.169] Module class: X.Org Video Driver
[ 22.169] ABI class: X.Org Video Driver, version 14.1
[ 22.169] (II) LoadModule: "vesa"
[ 22.169] (II) Loading /usr/lib64/xorg/modules/drivers/vesa_drv.so
[ 22.169] (II) Module vesa: vendor="X.Org Foundation"
[ 22.169] compiled for 1.14.2, module version = 2.3.2
[ 22.169] Module class: X.Org Video Driver
[ 22.169] ABI class: X.Org Video Driver, version 14.1
[ 22.169] (II) MGA: driver for Matrox chipsets: mga2064w, mga1064sg,
mga2164w,
mga2164w AGP, mgag100, mgag100 PCI, mgag200, mgag200 PCI,
mgag200 SE A PCI, mgag200 SE B PCI, mgag200 EV Maxim,
mgag200 ER SH7757, mgag200 eW Nuvoton, mgag200eH, mgag400, mgag550
[ 22.170] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[ 22.170] (II) FBDEV: driver for framebuffer: fbdev
[ 22.170] (II) VESA: driver for VESA chipsets: vesa
[ 22.170] (++) using VT number 1
[ 22.172] (EE) mga: The PCI device 0x522 at 07@00:02:0 has a kernel
module claiming it.
[ 22.172] (EE) mga: This driver cannot operate until it has been
unloaded.
[ 22.172] (EE) mga: The PCI device 0x522 at 07@00:02:0 has a kernel
module claiming it.
[ 22.172] (EE) mga: This driver cannot operate until it has been
unloaded.
[ 22.172] (II) modesetting(0): using drv /dev/dri/card0
[ 22.172] (WW) Falling back to old probe method for fbdev
[ 22.172] (II) Loading sub module "fbdevhw"
[ 22.172] (II) LoadModule: "fbdevhw"
[ 22.172] (II) Loading /usr/lib64/xorg/modules/libfbdevhw.so
[ 22.172] (II) Module fbdevhw: vendor="X.Org Foundation"
[ 22.172] compiled for 1.14.4, module version = 0.0.2
[ 22.172] ABI class: X.Org Video Driver, version 14.1
[ 22.172] (WW) Falling back to old probe method for vesa
[ 22.173] (II) modesetting(0): Creating default Display subsection in
Screen section
"Default Screen Section" for depth/fbbpp 24/32
[ 22.173] (==) modesetting(0): Depth 24, (==) framebuffer bpp 32
[ 22.173] (==) modesetting(0): RGB weight 888
[ 22.173] (==) modesetting(0): Default visual is TrueColor
[ 22.173] (II) modesetting(0): ShadowFB: preferred YES, enabled YES
[ 22.205] (II) modesetting(0): Output VGA-0 has no monitor section
[ 22.238] (II) modesetting(0): EDID for output VGA-0
[ 22.238] (II) modesetting(0): Manufacturer: DEL Model: 3010
Serial#: 1144075829
[ 22.238] (II) modesetting(0): Year: 2004 Week: 2
[ 22.238] (II) modesetting(0): EDID Version: 1.3
[ 22.238] (II) modesetting(0): Analog Display Input, Input Voltage
Level: 0.700/0.300 V
[ 22.238] (II) modesetting(0): Sync: Separate Composite SyncOnGreen
[ 22.238] (II) modesetting(0): Max Image Size [cm]: horiz.: 34 vert.: 27
[ 22.238] (II) modesetting(0): Gamma: 2.20
[ 22.238] (II) modesetting(0): DPMS capabilities: StandBy Suspend
Off; RGB/Color Display
[ 22.238] (II) modesetting(0): Default color space is primary color space
[ 22.238] (II) modesetting(0): First detailed timing is preferred mode
[ 22.238] (II) modesetting(0): redX: 0.646 redY: 0.359 greenX:
0.278 greenY: 0.612
[ 22.238] (II) modesetting(0): blueX: 0.145 blueY: 0.117 whiteX:
0.310 whiteY: 0.330
[ 22.238] (II) modesetting(0): Supported established timings:
[ 22.238] (II) modesetting(0): 720x400@70Hz
[ 22.238] (II) modesetting(0): 640x480@60Hz
[ 22.238] (II) modesetting(0): 640x480@75Hz
[ 22.238] (II) modesetting(0): 800x600@60Hz
[ 22.238] (II) modesetting(0): 800x600@75Hz
[ 22.238] (II) modesetting(0): 1024x768@60Hz
[ 22.238] (II) modesetting(0): 1024x768@75Hz
[ 22.238] (II) modesetting(0): 1280x1024@75Hz
[ 22.238] (II) modesetting(0): Manufacturer's mask: 0
[ 22.238] (II) modesetting(0): Supported standard timings:
[ 22.238] (II) modesetting(0): #0: hsize: 1152 vsize 864 refresh:
75 vid: 20337
[ 22.238] (II) modesetting(0): #1: hsize: 1280 vsize 1024 refresh:
60 vid: 32897
[ 22.238] (II) modesetting(0): Supported detailed timing:
[ 22.238] (II) modesetting(0): clock: 108.0 MHz Image Size: 338 x
270 mm
[ 22.238] (II) modesetting(0): h_active: 1280 h_sync: 1328
h_sync_end 1440 h_blank_end 1688 h_border: 0
[ 22.238] (II) modesetting(0): v_active: 1024 v_sync: 1025
v_sync_end 1028 v_blanking: 1066 v_border: 0
[ 22.238] (II) modesetting(0): Serial No: 2Y31741AD165
[ 22.238] (II) modesetting(0): Monitor name: DELL 1703FP
[ 22.238] (II) modesetting(0): Ranges: V min: 56 V max: 76 Hz, H min:
30 H max: 80 kHz, PixClock max 145 MHz
[ 22.238] (II) modesetting(0): EDID (in hex):
[ 22.238] (II) modesetting(0): 00ffffffffffff0010ac103035363144
[ 22.238] (II) modesetting(0): 020e01030e221b78ee8706a55c479c25
[ 22.239] (II) modesetting(0): 1e4f54a54b00714f8180010101010101
[ 22.239] (II) modesetting(0): 010101010101302a009851002a403070
[ 22.239] (II) modesetting(0): 1300520e1100001e000000ff00325933
[ 22.239] (II) modesetting(0): 3137343141443136350a000000fc0044
[ 22.239] (II) modesetting(0): 454c4c203137303346500a20000000fd
[ 22.239] (II) modesetting(0): 00384c1e500e000a202020202020001e
[ 22.239] (II) modesetting(0): Printing probed modes for output VGA-0
[ 22.239] (II) modesetting(0): Modeline "640x480"x75.0 31.50 640
656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz e)
[ 22.239] (II) modesetting(0): Modeline "640x480"x60.0 25.20 640
656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz e)
[ 22.239] (II) modesetting(0): Modeline "720x400"x70.1 28.32 720
738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz e)
[ 22.239] (II) modesetting(0): Output VGA-0 connected
[ 22.239] (II) modesetting(0): Using exact sizes for initial modes
[ 22.239] (II) modesetting(0): Output VGA-0 using initial mode
640x480 +0+0
[ 22.239] (II) modesetting(0): Using default gamma of (1.0, 1.0, 1.0)
unless otherwise stated.
[ 22.239] (==) modesetting(0): DPI set to (96, 96)
[ 22.239] (II) Loading sub module "fb"
[ 22.239] (II) LoadModule: "fb"
[ 22.239] (II) Loading /usr/lib64/xorg/modules/libfb.so
[ 22.240] (II) Module fb: vendor="X.Org Foundation"
[ 22.240] compiled for 1.14.4, module version = 1.0.0
[ 22.240] ABI class: X.Org ANSI C Emulation, version 0.4
[ 22.240] (II) Loading sub module "shadow"
[ 22.240] (II) LoadModule: "shadow"
[ 22.240] (II) Loading /usr/lib64/xorg/modules/libshadow.so
[ 22.240] (II) Module shadow: vendor="X.Org Foundation"
[ 22.240] compiled for 1.14.4, module version = 1.1.0
[ 22.240] ABI class: X.Org ANSI C Emulation, version 0.4
[ 22.240] (II) UnloadModule: "fbdev"
[ 22.240] (II) Unloading fbdev
[ 22.240] (II) UnloadSubModule: "fbdevhw"
[ 22.240] (II) Unloading fbdevhw
[ 22.240] (II) UnloadModule: "vesa"
[ 22.240] (II) Unloading vesa
[ 22.240] (==) Depth 24 pixmap format is 32 bpp
[ 22.241] (==) modesetting(0): Backing store disabled
[ 22.241] (==) modesetting(0): Silken mouse enabled
[ 22.241] (II) modesetting(0): RandR 1.2 enabled, ignore the
following RandR disabled message.
[ 22.241] (==) modesetting(0): DPMS enabled
[ 22.454] (--) RandR disabled
[ 22.464] (II) SELinux: Disabled by boolean
[ 22.465] (II) AIGLX: Screen 0 is not DRI2 capable
[ 22.465] (II) AIGLX: Screen 0 is not DRI capable
[ 26.542] (II) AIGLX: Loaded and initialized swrast
[ 26.549] (II) GLX: Initialized DRISWRAST GL provider for screen 0
[ 26.550] (II) modesetting(0): Damage tracking initialized
[ 26.550] (II) modesetting(0): Setting screen physical size to 169 x 127
[ 26.696] (II) config/udev: Adding input device Power Button
(/dev/input/event1)
[ 26.696] (**) Power Button: Applying InputClass "evdev keyboard
catchall"
... ... ...
[ 26.747] (II) No input driver specified, ignoring this device.
[ 26.747] (II) This device may have been added with another device file.
[ 32.144] (II) modesetting(0): EDID vendor "DEL", prod id 12304
[ 32.144] (II) modesetting(0): Using EDID range info for horizontal sync
[ 32.144] (II) modesetting(0): Using EDID range info for vertical refresh
[ 32.145] (II) modesetting(0): Printing DDC gathered Modelines:
[ 32.145] (II) modesetting(0): Modeline "1280x1024"x0.0 108.00 1280
1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz eP)
[ 32.145] (II) modesetting(0): Modeline "800x600"x0.0 40.00 800
840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz e)
[ 32.145] (II) modesetting(0): Modeline "640x480"x0.0 31.50 640
656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz e)
[ 32.145] (II) modesetting(0): Modeline "640x480"x0.0 25.18 640
656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz e)
[ 32.145] (II) modesetting(0): Modeline "720x400"x0.0 28.32 720
738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz e)
[ 32.145] (II) modesetting(0): Modeline "1280x1024"x0.0 135.00 1280
1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (80.0 kHz e)
[ 32.145] (II) modesetting(0): Modeline "1024x768"x0.0 78.75 1024
1040 1136 1312 768 769 772 800 +hsync +vsync (60.0 kHz e)
[ 32.145] (II) modesetting(0): Modeline "1024x768"x0.0 65.00 1024
1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz e)
[ 32.145] (II) modesetting(0): Modeline "800x600"x0.0 49.50 800
816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz e)
[ 32.145] (II) modesetting(0): Modeline "1152x864"x0.0 108.00 1152
1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz e)
[ 35.321] (II) modesetting(0): EDID vendor "DEL", prod id 12304
[ 35.321] (II) modesetting(0): Using hsync ranges from config file
[ 35.321] (II) modesetting(0): Using vrefresh ranges from config file
[ 35.321] (II) modesetting(0): Printing DDC gathered Modelines:
[ 35.321] (II) modesetting(0): Modeline "1280x1024"x0.0 108.00 1280
1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz eP)
[ 35.321] (II) modesetting(0): Modeline "800x600"x0.0 40.00 800
840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz e)
[ 35.321] (II) modesetting(0): Modeline "640x480"x0.0 31.50 640
656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz e)
[ 35.321] (II) modesetting(0): Modeline "640x480"x0.0 25.18 640
656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz e)
[ 35.321] (II) modesetting(0): Modeline "720x400"x0.0 28.32 720
738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz e)
[ 35.321] (II) modesetting(0): Modeline "1280x1024"x0.0 135.00 1280
1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (80.0 kHz e)
[ 35.321] (II) modesetting(0): Modeline "1024x768"x0.0 78.75 1024
1040 1136 1312 768 769 772 800 +hsync +vsync (60.0 kHz e)
[ 35.321] (II) modesetting(0): Modeline "1024x768"x0.0 65.00 1024
1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz e)
[ 35.321] (II) modesetting(0): Modeline "800x600"x0.0 49.50 800
816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz e)
[ 35.321] (II) modesetting(0): Modeline "1152x864"x0.0 108.00 1152
1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz e)
[ 137.239] (II) modesetting(0): EDID vendor "DEL", prod id 12304
[ 137.239] (II) modesetting(0): Using hsync ranges from config file
[ 137.239] (II) modesetting(0): Using vrefresh ranges from config file
[ 137.239] (II) modesetting(0): Printing DDC gathered Modelines:
[ 137.239] (II) modesetting(0): Modeline "1280x1024"x0.0 108.00 1280
1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz eP)
[ 137.239] (II) modesetting(0): Modeline "800x600"x0.0 40.00 800
840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz e)
[ 137.239] (II) modesetting(0): Modeline "640x480"x0.0 31.50 640
656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz e)
[ 137.239] (II) modesetting(0): Modeline "640x480"x0.0 25.18 640
656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz e)
[ 137.239] (II) modesetting(0): Modeline "720x400"x0.0 28.32 720
738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz e)
[ 137.239] (II) modesetting(0): Modeline "1280x1024"x0.0 135.00 1280
1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (80.0 kHz e)
[ 137.239] (II) modesetting(0): Modeline "1024x768"x0.0 78.75 1024
1040 1136 1312 768 769 772 800 +hsync +vsync (60.0 kHz e)
[ 137.239] (II) modesetting(0): Modeline "1024x768"x0.0 65.00 1024
1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz e)
[ 137.239] (II) modesetting(0): Modeline "800x600"x0.0 49.50 800
816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz e)
[ 137.239] (II) modesetting(0): Modeline "1152x864"x0.0 108.00 1152
1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz e)
[ 137.978] (II) modesetting(0): EDID vendor "DEL", prod id 12304
[ 137.978] (II) modesetting(0): Using hsync ranges from config file
[ 137.978] (II) modesetting(0): Using vrefresh ranges from config file
[ 137.978] (II) modesetting(0): Printing DDC gathered Modelines:
[ 137.978] (II) modesetting(0): Modeline "1280x1024"x0.0 108.00 1280
1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz eP)
[ 137.978] (II) modesetting(0): Modeline "800x600"x0.0 40.00 800
840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz e)
[ 137.978] (II) modesetting(0): Modeline "640x480"x0.0 31.50 640
656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz e)
[ 137.978] (II) modesetting(0): Modeline "640x480"x0.0 25.18 640
656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz e)
[ 137.979] (II) modesetting(0): Modeline "720x400"x0.0 28.32 720
738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz e)
[ 137.979] (II) modesetting(0): Modeline "1280x1024"x0.0 135.00 1280
1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (80.0 kHz e)
[ 137.979] (II) modesetting(0): Modeline "1024x768"x0.0 78.75 1024
1040 1136 1312 768 769 772 800 +hsync +vsync (60.0 kHz e)
[ 137.979] (II) modesetting(0): Modeline "1024x768"x0.0 65.00 1024
1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz e)
[ 137.979] (II) modesetting(0): Modeline "800x600"x0.0 49.50 800
816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz e)
[ 137.979] (II) modesetting(0): Modeline "1152x864"x0.0 108.00 1152
1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz e)
[ 148.728] (II) evdev: MCE IR Keyboard/Mouse (cx88xx): Close
[ 148.728] (II) UnloadModule: "evdev"
[ 148.728] (II) evdev: ServerEngines SE USB Device: Close
[ 148.728] (II) UnloadModule: "evdev"
[ 148.728] (II) evdev: ServerEngines SE USB Device: Close
[ 148.728] (II) UnloadModule: "evdev"
[ 148.728] (II) evdev: HID 413c:3010: Close
[ 148.728] (II) UnloadModule: "evdev"
[ 148.729] (II) evdev: cx88 IR (Hauppauge Nova-S-Plus : Close
[ 148.729] (II) UnloadModule: "evdev"
[ 148.729] (II) evdev: Power Button: Close
[ 148.729] (II) UnloadModule: "evdev"
[ 148.729] (II) evdev: Power Button: Close
[ 148.729] (II) UnloadModule: "evdev"
[ 149.170] (EE) Server terminated successfully (0). Closing log file.
--
Morgan Read
NEW ZEALAND
<mailto:mstuffATreadDOTorgDOTnz>
Confused about DRM?
Get all the info you need at:
http://drm.info/
10 years
Five Things in Fedora This Week -- LAST WEEK edition (2014-04-15)
by Matthew Miller
In all of the hubbub of Red Hat Summit, I forgot to post this to the
mailing lists. Well, better late than never, I guess. Here's last
week's Five Things in Fedora This Week, reposted from
http://fedoramagazine.org/five-things-in-fedora-this-week-2014-04-15/
Fedora is a big project, and it’s hard to follow it all. This series
highlights interesting happenings in five different areas every week.
It isn’t comprehensive news coverage — just quick summaries with links
to each. Here are the five things for April 15th, 2014:
Live from Red Hat Summit
------------------------
I'm posting this from the Fedora booth at Red Hat Summit in San
Francisco. The Summit is Red Hat's annual showcase conference, and of
course we have a good Fedora presence. Fedora Project Leader Robyn
Bergeron is on the scene; Ruth Suehle is setting up a demo on the big
TV behind us; and Tom Callaway has the Lulzbot up and making 3D prints.
If you're at Summit, come by and say hello, ask questions, tell us
answers, and so on. (Except, don't, because, remember, this was
actually last week.)
* http://www.redhat.com/summit/
* https://www.lulzbot.com/
Testing Rawhide
---------------
Rawhide is Fedora's continuously updated development tree. Long ago, it
came with the scary warning that it would "eat babies" and other
horrible things, but that's been *gone* from the official line for
about five years now. In fact, if you're up for a little adventure (and
have a second computer to get work done if it goes wrong), we'd love
you to help test.
Fedora QA Community Monkey¹ Adam Williamson recently revamped the
Rawhide wiki page to be more useful and clear, and launched an
initiative for quality assurance volunteers to do ongoing validation
testing so any problems are caught long before release. If this sounds
interesting, join the Fedora QA team and help out.
I run Rawhide on my main desktop system but not my travel laptop; that
way, I can always get some work done even when there's a problem. But,
really, it's been mostly painless. I recommend keeping active on the
mailing lists and checking the Rawhide Watch and This Week in Rawhide
blogs daily.
* https://lwn.net/Articles/320669/
* https://fedoraproject.org/wiki/Releases/Rawhide
* https://lists.fedoraproject.org/pipermail/test/2014-April/120931.html
* https://fedoraproject.org/wiki/QA
* http://rawhidewatch.wordpress.com/
* http://www.scrye.com/wordpress/nirik/category/rawhide/
(1. That's Adam's semi-official title.)
Fedora Heartbleed Followup
--------------------------
Last week's main excitement — not just in Fedora! — was the
"Heartbleed" vulnerability in OpenSSL, referred to by the
industry-standard Common Vulnerabilities and Exposures identifier
`CVE-2014-0160`. (If you missed the official Fedora updates, see Update
on CVE-2014-0160, aka “Heartbleed” and Fedora Infrastructure
information on Openssl vulnerability.)
I think our response to this went fairly well overall, but there's
always something to be learned from these incidents and things we could
do better. There are two specific areas where I think we could improve.
First, our normal process of releasing updates requires a lot of data
crunching. I think it'd be useful to have a separate "urgent updates"
repository that would enable us to get updates to users more quickly
once they are ready to go. Second, it would be nice to have a standard
process for getting packagers, a communications team, security experts,
quality assurance, release engineers, and other responders "on the
scene" quickly — a sort of "Fedora bat-signal." Both of these ideas
need some development, of course.
Another important thing we can do in advance is develop more test cases
for key software. These can be followed as part of making sure updates
are good to be pushed to users, rather than relying on ad hoc
assessments ("works for me!"). This is an area where anyone can
contribute — you don't have to be a coder or a package maintainer. Pick
a package that's interesting to you and take a look at the instructions
for creating a test case.
* http://cve.mitre.org/
* http://fedoramagazine.org/update-on-cve-2014-0160-aka-heartbleed/
* http://wp.me/p3XX0v-nH
* https://fedorahosted.org/rel-eng/ticket/5886
* https://fedorahosted.org/fesco/ticket/1278
* http://fedoraproject.org/wiki/QA:SOP_test_case_creation
Fedocal — the Fedora Project calendar
-------------------------------------
A couple of weeks ago, I mentioned that the Fedora wiki is weighed down
by too many different uses. One of those uses is scheduling: wiki pages
and wiki tables are used as editable calendars. If you've ever tried to
update one of these, you know that it can be painful. But we have a
better tool: Fedocal.
Fedora hackers Pierre-Yves Chibon (a.k.a. pingou) and Ralph Bean
(threebean) recently added location support, which means that IRC-based
meetings can use that for scheduling. In general, if you're scheduling
something in Fedora, this is the tool to use. Let's avoid further wiki
abuse!
* http://fedocal.readthedocs.org/en/latest/
* https://apps.fedoraproject.org/calendar/
* https://apps.fedoraproject.org/calendar/locations/
* https://fedoraproject.org/wiki/Meeting_channel
Upcoming FUDCons
----------------
Although the North American and European events are replaced by Flock
to Fedora, our Fedora User and Developer Conferences are going strong
worldwide. Upcoming events include FUDCon Beijing 2014 and FUDCon
Managua 2014 in Nicaragua.
Also, speaking of Flock, don't forget to vote on session proposals.
* http://flocktofedora.org/
* https://fedoraproject.org/wiki/FUDCon:Beijing_2014
* https://fedoraproject.org/wiki/FUDCon:Managua_2014
* https://admin.fedoraproject.org/voting
Thanks this week to Ankur Sinha for feeding me notes from Fedora
Ambassadors meetings!
--
Matthew Miller -- Fedora Project -- <mattdm(a)fedoraproject.org>
"Tepid change for the somewhat better!"
10 years
how to report a nouveau bug?
by Aleksandar Kostadinov
Hello,
I want to report a freeze with latest fedora 3.13 kernel just on login
screen. The issue is not present on the initial kernel coming with
fedora 20 life CD.
The problem is that when I boot I can't switch to a text console after
the freeze. I don't have good access to the laptop because it's my
mother's so I'm wondering what would be the easiest way to collect
useful information and report it.
btw I think it is nouveau issue because I see some messages realated to
nouveau just before entering graphics mode.
Perhaps I can boot to the freeze, then reboot into older kernel, and
collect the log but my there is some risk the log to not be complete due
to unclean reboot. As well I'm not sure if plain log is enough. I would
like to file a good bug report from the first attempt to avoid the
hassle repeating the operation for small details.
Thanks!
10 years
Re: F20 Where's my system mail?
by Andreas M. Kirchwitz
Arthur Dent <misc.lists(a)blueyonder.co.uk> wrote:
> I have read this page:
> https://fedoraproject.org/wiki/Changes/NoDefaultSendmail
Yes, Fedora's great plan of no default sendmail basically means that
they simply do no longer install sendmail (default MTA). That's all.
All software (crond, raid-check, logwatch etc.) still sends mail,
but now it just gets silently deleted.
A good concept for system design would have taken into account that
software needs new configuration on how to deal with the information
that was sent out via mail previously. There's no point in still having
all software configured to send out mail but not installing an MTA.
That doesn't solve the problem.
> Without a functioning MTA how can I now achieve the same result?
> Although I can ssh into the box, and I do often check logs etc, it is
> reassuring to know when something has happened I would get an email, and
> the regular output in email-form from logwatch was something I would
> check every day.
>
> Can I get this functionality back without the pain of configuring
> postfix or (shudder) sendmail? If so how?
Fedora still offers MTA software, eg sendmail, in their repositories
(so you get all security updates, bug fixes etc.) After your fresh
installation of F20 you could simply run "yum install sendmail" and
have the exact same setup as all the years before.
However, I agree, that having a full-blown MTA on a desktop PC is
somewhat weird. I've tried to go with "msmtp" (supported by Fedora).
It's basically a "mail forwarder". It offers a "sendmail"-style
binary and forwards all input to a preconfigured SMTP host (each
user can have its own configuration).
At first, "msmtp" looked like a good solution, but the configuration
overhead was much higher than putting a smart-host in sendmail.cf.
Finally, I got msmtp working but I'm still not really happy
(it doesn't rewrite destination addresses for aliased forwards,
and that's a big problem with today's spam filters), so I will
revert to sendmail in F21.
Alternatively, you could install procmail and reconfigure all
software to use procmail instead of sendmail to handle mail.
Procmail allows delivery to local mailboxes if that's all you need.
In my setup, I don't want local mail on my desktop PCs (that's
indeed useless) but have all mail forwarded to a SMTP smart-host
(where my primary mail-account is located).
Another alternative is mailx. It even allows for remote
delivery. Sounds really cool. But totally fails on SMTP servers
with self-signed certificates. That's uncool.
In any case, reconfiguring all software to use something different
than the old-school "sendmail" binary requires more time than just
installing (and configuring) sendmail itself.
As long as Fedora still officially supports sendmail in their
repositories, all is well.
Greetings, Andreas
10 years
FFTW with mpi support
by Brahmanand Jogai
I am attempting to compile an application (MPB from MIT) with support
for MPI. It needs fast fourier transform with MPI support. Fedora 20
provides several versions of fftw, but none has support for either
openmpi or mpich2.
Does anyone know of a repo that has fftw with mpi? I have not found
anything on google. I tried compiling fftw from source, but it failed
its own self tests. Besides, installing a home built fftw could affect
other applications that depend on the Fedora-supplied one.
Any suggestion will be appreciated.
10 years
BOINCMGR fails
by Andrew Gray
Hi All
Ever since I have been on Fedora 20 bonicmgr fails to add any
projects !!
I normally run boincmgr ar root !!
Therefore I am unable to run Seti or any other projects with
bonic-client !!
Does anyone else have this problem!
--
Andrew Gray <andrewg(a)linnetsol.co.uk>
Linnet Solutions Ltd
10 years