June 2009 - openSUSE Users (Español) - openSUSE Mailing Lists

[opensuse-es] duda sobre wine
by Juan Carlos Garcia 17 Jun '09

17 Jun '09

Hola, tengo algo trivial. me encontre con wine y me preguntaron si podia ejecutar tambien videojuegos, buscando en la red ya encontre mucha ayuda particularmente estoy tratando de hacer correr Wow con wine me apoye aqui: http://forums.wow-europe.com/thread.html?topicId=271577272&sid=4 pero al final obtengo que no corre, me manda un error wine. err:module:attach_process_dlls "DivxDecoder.dll" failed to initialize, aborting err:module:LdrInitializeThunk Main exe initialization for L"Z:\\windows\ \C\\Documents and Settings\\Administrador\\Mis documentos\\wow\\World of Warcraft\\Wow.exe" failed, status c0000005 juan@linux-kgcq:/windows/C/Documents and Settings/Administrador/Mis documentos/wow/World of Warcraft> Si alguien tiene alguna sugerencia, pues muchas gracias, si no, pues seguire buscando a ver que encuentro... de cualquier modo, mil gracias -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe(a)opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help(a)opensuse.org

3 2

[opensuse-es] Problema con K3B.
by Mauro Antivero 17 Jun '09

17 Jun '09

Hola gente cómo les va tanto tiempo? Les escribo para ver si me pueden ayudar con el siguiente problema: Hace unos días cuando me dispuse a grabar un DVD con K3B este lo hacía pero muy léntamente, el buffer del dispositivo se vaciaba contínuamente y además se "alentaba" toda la PC, osea el uso del procesador se me disparaba al 100%. Como es de costumbre, no recuerdo haber toqueteado nada en el sistema como para sospechar de algo que pueda haber hecho. Descarto problemas de Hardware ya que en Win graba lo más bien. De momento voy a probar actualizar K3B, me aparece en YAST una pequeña actualización disponible, voy a ver que pasa. Sino hay algún log que tenga K3B en el que pueda mirar para tener una idea de porque hace eso? Por cierto, creo que al mismo tiempo que empezó esa falla K3B me daba una advertencia la inicio (cosa que antes no hacía) pero sobre que no encontraba los archivos necesario para decodificar MP3. Dudo mucho que eso tenga algo que ver ya que eso se debía a la falta de libmad, lo que no entiendo es porque pasó si antes no lo hacía. Por ahora pruebo con la actualización a ver que pasa, comento luego. Mientras tanto se agradecen ideas. Muchas gracias desde ya y saludos! -- Para dar de baja la suscripciÃ³n, mande un mensaje a: opensuse-es+unsubscribe(a)opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help(a)opensuse.org

7 34

[opensuse-es] [Info] Drizzle: La evolucion de mysql
by Juan Erbes 17 Jun '09

17 Jun '09

http://www.linux-mag.com/cache/7379/1.html https://launchpad.net/drizzle https://code.launchpad.net/drizzle/trunk Para los que no puedan acceder al articulo de Linux Magazine, les pego el texto (no se habras algun voluntario para traducirlo): Drizzle is a re-thought and re-worked version of the MySQL kernel designed specifically for high-performance, high-concurrency environments. In this exclusive article, MySQL guru Jeremy Zawodny takes an inside look at the goals and state of Drizzle development. Drizzle is building a database optimized for cloud and [network] applications. [Drizzle] is being designed for massive concurrency on modern multi-cpu/core architectures. The code is originally derived from MySQL. In other words, Drizzle is a re-thought and re-worked version of the MySQL kernel designed specifically for high-performance, high-concurrency environments. The goal is to make Drizzle an extensible database kernel that runs extremely fast on emerging hardware. Much like Linux is a fast kernel that can be extended with loadable modules (notably filesystems and device drivers, among others), Drizzle explicitly says “no” to building in some features, instead pushing them out of the core and into plug-ins. This separation allows Drizzle to focus on only the most essential features of a modern database kernel. In fact, it’s almost a become a joke on the Drizzle mailing list that someone will say “Make it a plugin!” when anyone questions removing functionality from the server. At this point you may be wondering who would be crazy enough to think that MySQL, known for its speed and agility, needs to be radically re-worked. After all, it’s been the dominant open source relational database for the better part of a decade now. The Drizzle project is headed by Brian Aker, the former director of architecture for MySQL. Aker now works in the Office of the Chief Technology Officer at Sun (soon to be Oracle) and heads up a team of developers working on Drizzle and a few other projects (see one of Aker’s early posts on Drizzle). Some of those developers are Sun employees (Eric Day, Jay Pipes, Monty Taylor, Mark Atwood, and others), while others are either volunteers or contributing to Drizzle on behalf of their employer. Toru Maesaka of Mixi is one such developer. A lot of the Drizzle work is driven by significant changes in hardware that have occurred since widespread adoption of MySQL began. Before discussing what Drizzle is and is not, it’s important to understand a bit about the last 5-7 years of evolution in hardware and systems and the challenges those presented to MySQL users, especially those who were constantly pushing the envelope of what’s possible. Moore’s Law Turned Sideways The most significant change in recent hardware history is that Moore’s Law took a surprising turn. For years, developers have been able to depend on the clock speed of CPUs doubling roughly every 18 months. In other words, the code you ran in early 2001 would be more than twice as fast if you simply upgraded the CPU in your server in late 2002. Why “more than” twice as fast? Not only did clock speeds increase, changes in the architecture of CPUs made them more efficient, too: larger caches, more registers, better instruction pipelines, and so on. This doubling trend went on for so long that Moore’s Law was practically law and something destined to continue for the foreseeable future. But then something strange happened a couple years ago. Instead of seeing 4 GHz CPUs appear to replace 3.2 GHz CPUs, Intel and AMD started pushing multi-core CPUs that ran at slower clock speeds. Effectively, the megahertz and gigahertz game had come to an end. Instead of pure “vertical” scaling, Moore’s Law had been redirected along a different axis: horizontal scaling. At the 2009 MySQL Conference, Sun co-founder Andy Bechtolsheim delivered a keynote presentation called The Solid State Storage Revolution, which contained a chart plotting CPU clock speeds over the last 20 years or so. It illustrated this sudden change very clearly and removed any doubt about where things are headed. (Sadly, his slides are not available online). In a sense this isn’t new. Symmetric multiprocessing (SMP) has been around for years now in the form of motherboards with two or four physically separate CPUs. But having multiple CPU cores on the same physical chip was a new approach. Intel previewed the future with the introduction of Hyper-Threadingon some Pentium 4 CPUs. The technology allowed a single CPU to run two execution threads in parallel. It’s not the same as having two physical cores on the same chip, but it was a nice boost at the time. With Moore’s Law overturned, the new road to efficiency and performance is to design for concurrency and parallelism. Any problem that can be split into sub-problems and executed in parallel fits this new world very well. As you’ll see momentarily, there are places where MySQL is able to exploit multi-core well, but others in which it was of no help at all. RAID and RAM As with all things hardware, the cost of running substantial RAID arrays (6-12 disks) with battery-backed write caches has dropped substantially. That doesn’t mean that disk I/O isn’t still the single biggest bottleneck in large databases—it is. Any time your data size grows substantially beyond what can fit in RAM, I/O bottlenecks appear. But today’s “commodity” hardware lets you push that barrier out quite a long way. Thanks to commodity 64-bit CPUs, it’s not hard to find a server than can be loaded with 64 GB or even 128 GB of memory. That alone is sufficient to keep a very large percentage of MySQL deployments from having to worry about going to disk that often. But what about those really big deployments? The transfer rates of modern disks and their controllers is measured hundreds of megabytes per second. But that’s assuming a best case scenario: linear (sequential) reads or writes. The real killer is random disk I/O. Any time the disk head needs to move (seek), you incur a delay of several milliseconds. Event the fastest hard disks available claim average seek times in the 4 ms range. Expecting more than about 200 seeks per second is unrealistic. In fact, the rule of thumb for years has been not to expect more than about 100 I/O operations (iops) from a single spindle. Having larger disk arrays means being able to perform a greater number of iops per second: typically something like (N/2)*100 where N is the number of disks. You must divide by two because of mirroring. In a typical setup of 12 disks, there are 6 mirrored pairs (RAID-1) and stripe (RAID-0) data across them. This is commonly referred to as RAID 1+0. Using this model, the only way to get another 200 iops out of your array (without sacrificing data integrity) is to add two or four more disks. Like Moore’s Law, this had been true for a very long time. But just like Moore’s Law, the storage game has recently changed in a most unexpected way. Fast Networks and Memcached The classic LAMP architecture has quietly been evolving to incorporate new pieces, largely thanks to gigabit Ethernet (which provides disk-like transfer speeds), 64-bit CPUs, and dropping RAM prices. Many high-volume web sites have added a “caching tier” to their architecture. This caching tier is often based on memcached and sits between the application layer and the database. Refactoring, Removing, and Plugins As you can see, many of the fundamental features of systems have evolved and changed since MySQL began it’s hockey stick growth nearly a decade ago. When you combine that with the organic growth of MySQL’s code base over the years and all the features that have been crammed into it, you end up with a code base that, to put it politely, needs work. So Aker and team have set out to modernize the code, removing old abstractions that are no longer relevant (mysys), removing custom code and replacing it with modern C++ data structures and algorithms, and fixing up various inconsistencies. Along the way the team has been ruthlessly removing needless locks (mutexes) that would greatly reduce concurrency and overall throughput. The SHOW PROCESSLIST command in MySQL is a perfect example. Every time you run it on a server, it grabs a global lock that is not released until it has finished reading all the information about the state of threads in the server, including the text of currently executing queries. Now that’s something that happens very quickly on most servers, but what about a 64- or 128-core server (available today) running thousands of queries per second? Even a stall of a few milliseconds can really back things up. Worse, you’re more likely to run SHOW PROCESSLIST when trying to debug why a server has slowed down. In doing so, you’d further degrade the situation. Hence, the Drizzle implementation of SHOW PROCESSLIST no longer performs any locking. It’s effectively performing a dirty read of the thread status. And that’s just fine for 99.999% of uses. As the team has combs through the code, it occasionally stumbles upon a feature that adds complexity to the system (or reduces concurrency) and asks if it’s worth keeping. Often times the answer is no. The result is that many features have been dropped entirely and others are being moved to plugins. What’s Gone Here’s a short list of some major features that have been removed from Drizzle. With the popularity of memcached and other application level caching, the need for a query cache has decreased over time. It was of limited utility in high-volume applications because every update to a table would invalidate all related entries in the cache. Moreover, locking in the query cache was not nearly granular enough. Hence, it’s been removed from Drizzle. Triggers have been removed with an eye toward re-adding them once a proper plug-in interface can be defined. The MyISAM storage engine that served as the bedrock of MySQL for many years does not exist in Drizzle. It suffered from very poor concurrency and maintaining support for it “contaminated” other parts of the server code. InnoDB is the default storage engine in Drizzle. Both the Event Scheduler and Stored Procedures have been elided while developers debate the merits of having them in the kernel and/or developing a reasonable API to support different schedulers and stored procedures in multiple languages. Views are gone but are expected to reappear with a better implementation at some point. Prepared Statements are gone as well. The implementation in MySQL had numerous problems to begin with, plus Drizzle has a new protocol which allows for a better implementation in the future. Replication has been removed in favor of a more flexible, modular logging system upon which its replacement can be built. There are numerous other changes in Drizzle as well. Character sets are gone. Everything in Drizzle is UTF-8. And the variety of column types has been greatly reduced as well. A list of the differences between Drizzle and MySQL is available. What’s New? The old MySQL protocol and the client libraries have been re-thought and re-implemented. The protocol work itself is now part of the libdrizzle sub-project that’s used by both the server and client utilities, as well as any other projects that wish to talk to Drizzle servers. Aside from simply being more efficient, the protocol allows for checksums on data, has built-in sharding support, and support for connecting via TCP, UDP, and Unix Domain Sockets. When used over TCP or UDS, the protocol is “full-duplex”, which means that the client and server can preempt otherwise long operations to cancel them or provide additional information (errors, warnings, and the like). To ease migration, libdrizzle completely supports the MySQL protocol as well, so you can build applications using libdrizzle that talk to either Drizzle or MySQL servers. If you ever move from MySQL to Drizzle, this feature will be invaluable. If you’d like to know more, have a look at the Drizzle protocol draft. The on-disk format for table definitions (.frm files) has been replaced with a representation based on Google Protocol Buffers. This removes a lot of custom code from the server and makes it easier for other tools to understand table definitions as well. While not an end-user feature, the development model around Drizzle is new, too. It’s completely open (unlike MySQL) and is very easy to get involved with. Testing is a big focus for the Drizzle team. When the team compiles Drizzle, every compiler warning is treated as an error, and each new build is checked against previous builds for any performance regressions. When a regression occurs, no new code is committed to the trunk until the source of the regression has been identified and fixed. A recent example involved the tcmalloc library. Brian Aker discusses some of the testing philosophy in Drizzle, State of Testing. Getting Involved As noted earlier, Drizzle has a very open and approachable development model. The first thing you’ll probably want to do is check out and build a copy of the source code. That means building and installing both libdrizzle and Drizzle itself. You’ll need a few prerequisites, many of which are probably already on your system, but the configure script will notify you of any omissions. The most problematic tends to be Google Protocol Buffers. You may need to build and install the package from source if the package repository for your distribution doesn’t have an up-to-date version available. Once you have the prerequisities, the builds are simple enough. $ bzr branch lp:libdrizzle $ cd libdrizzle $ ./config/autorun.sh $ ./configure $ make $ make test $ sudo make install $ bzr branch lp:drizzle $ cd drizzle $ ./config/autorun.sh $ ./configure $ make $ make test The commands yield an installed copy of libdrizzle and a locally-built Drizzle server that you can start (without installing) by simply running drizzled/drizzled --datadir=/tmp. And then you’re off and running. You can connect to the Drizzle server and use it in much the same way you use MySQL today. To get move involved, here are some links to visit: * Drizzle Client and Protocol Library (libdrizzle) * Drizzle Project on Launchpad * Drizzle Wiki * drizzle-discuss mailing list * drizzle-jdbc (a JDBC driver for Drizzle) * Drizzle PHP Extension * DBD::Drizzle (Perl) Keep in mind that the Drizzle team does not believe that Drizzle is ready for prime-time yet. However, that hasn’t stopped some people from using it on a daily basis. Nonetheless, the project is still evolving at a rapid pace, so if you do plan to use Drizzle soon, it’s best to stay informed about what’s going on in the project. And, by all means, report any bugs you find! Jeremy Zawodny is a software engineer at Craigslist where he works on MySQL, Search, and various back-end infrastructure. He's also the co-author of "High Performance MySQL" and blogs at http://jeremy.zawodny.com/blog/ -- USA LINUX OPENSUSE QUE ES SOFTWARE LIBRE, NO NECESITAS PIRATEAR NADA Y TAMPOCO TE VAS A PREOCUPAR MAS POR LOS VIRUS Y SPYWARES: http://www.opensuse.org/es/ -- Para dar de baja la suscripciÃ³n, mande un mensaje a: opensuse-es+unsubscribe(a)opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help(a)opensuse.org

1 0

[opensuse-es] Geeko Builder
by Xavier Barnada 17 Jun '09

17 Jun '09

Novell ha creado un concurso para personalizar Geeko , la mascota de OpenSuse, aqui os dejo un articulo que lo explica mejor: http://actualidad.espaciolinux.com/2009/06/13/3575/ y un enlace directo a la web: http://www.geekobuilder.es/ -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe(a)opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help(a)opensuse.org

6 7

[opensuse-es] Autenticacion obligatoria en postfix
by Jaime Velez 16 Jun '09

16 Jun '09

Cordial saludo a la lista esto creo que lo pregunte hace años.. pero igual se me olvido estoy en la latera de instalar a punta de clicks un servidor LDAP (que aqui y ahora es muy facil) en una opensuse 11.1 y despues de eso, pegarselo a todo lo que se pueda (ya lo puse a funcionar con cyrus, con samba con openfire, con ssh y con postfix) y ademas es una muy bonita libreta de direcciones que funciona bastante bien con thunderbird y kontact (me parece que evolution es un poco aparatoso) espero proximanete ponerlo o a manerade manual por si a alguien le interesa... el problrma es algo que ya habia preguntado hace años .. como hago la autenticación con sasl contra postfix obligatoria, los usuarios se autentican bien, pero igual mandan si no se autentican, y quiero que autenticarse sea obligatorio de donde sea la configuracion de postfix es esta ********************* # ----------------------------------------------------------------------- # NOTE: Many parameters have already been added to the end of this file # by SuSEconfig.postfix. So take care that you don't uncomment # and set a parameter without checking whether it has been added # to the end of this file. # ----------------------------------------------------------------------- # # Global Postfix configuration file. This file lists only a subset # of all parameters. For the syntax, and for a complete parameter # list, see the postconf(5) manual page (command: "man 5 postconf"). # # For common configuration examples, see BASIC_CONFIGURATION_README # and STANDARD_CONFIGURATION_README. To find these documents, use # the command "postconf html_directory readme_directory", or go to # http://www.postfix.org/. # # For best results, change no more than 2-3 parameters at a time, # and test if Postfix still works after every change. # SOFT BOUNCE # # The soft_bounce parameter provides a limited safety net for # testing. When soft_bounce is enabled, mail will remain queued that # would otherwise bounce. This parameter disables locally-generated # bounces, and prevents the SMTP server from rejecting mail permanently # (by changing 5xx replies into 4xx replies). However, soft_bounce # is no cure for address rewriting mistakes or mail routing mistakes. # #soft_bounce = no # LOCAL PATHNAME INFORMATION # # The queue_directory specifies the location of the Postfix queue. # This is also the root directory of Postfix daemons that run chrooted. # See the files in examples/chroot-setup for setting up Postfix chroot # environments on different UNIX systems. queue_directory=/var/spool/postfix # The command_directory parameter specifies the location of all # postXXX commands. command_directory=/usr/sbin # The daemon_directory parameter specifies the location of all Postfix # daemon programs (i.e. programs listed in the master.cf file). This # directory must be owned by root. daemon_directory=/usr/lib/postfix # The data_directory parameter specifies the location of Postfix-writable # data files (caches, random numbers). This directory must be owned # by the mail_owner account (see below). data_directory=/var/lib/postfix # QUEUE AND PROCESS OWNERSHIP # # The mail_owner parameter specifies the owner of the Postfix queue # and of most Postfix daemon processes. Specify the name of a user # account THAT DOES NOT SHARE ITS USER OR GROUP ID WITH OTHER ACCOUNTS # AND THAT OWNS NO OTHER FILES OR PROCESSES ON THE SYSTEM. In # particular, don't specify nobody or daemon. PLEASE USE A DEDICATED # USER. mail_owner=postfix # The default_privs parameter specifies the default rights used by # the local delivery agent for delivery to external file or command. # These rights are used in the absence of a recipient user context. # DO NOT SPECIFY A PRIVILEGED USER OR THE POSTFIX OWNER. # #default_privs = nobody # INTERNET HOST AND DOMAIN NAMES # # The myhostname parameter specifies the internet hostname of this # mail system. The default is to use the fully-qualified domain name # from gethostname(). $myhostname is used as a default value for many # other configuration parameters. # #myhostname = host.domain.tld #myhostname = virtual.domain.tld # The mydomain parameter specifies the local internet domain name. # The default is to use $myhostname minus the first component. # $mydomain is used as a default value for many other configuration # parameters. # #mydomain = domain.tld # SENDING MAIL # # The myorigin parameter specifies the domain that locally-posted # mail appears to come from. The default is to append $myhostname, # which is fine for small sites. If you run a domain with multiple # machines, you should (1) change this to $mydomain and (2) set up # a domain-wide alias database that aliases each user to # user(a)that.users.mailhost. # # For the sake of consistency between sender and recipient addresses, # myorigin also specifies the default domain name that is appended # to recipient addresses that have no @domain part. # #myorigin = $myhostname #myorigin = $mydomain # RECEIVING MAIL # The inet_interfaces parameter specifies the network interface # addresses that this mail system receives mail on. By default, # the software claims all active interfaces on the machine. The # parameter also controls delivery of mail to user(a)[ip.address]. # # See also the proxy_interfaces parameter, for network addresses that # are forwarded to us via a proxy or network address translator. # # Note: you need to stop/start Postfix when this parameter changes. # #inet_interfaces = all #inet_interfaces = $myhostname #inet_interfaces = $myhostname, localhost # The proxy_interfaces parameter specifies the network interface # addresses that this mail system receives mail on by way of a # proxy or network address translation unit. This setting extends # the address list specified with the inet_interfaces parameter. # # You must specify your proxy/NAT addresses when your system is a # backup MX host for other domains, otherwise mail delivery loops # will happen when the primary MX host is down. # #proxy_interfaces = #proxy_interfaces = 1.2.3.4 # The mydestination parameter specifies the list of domains that this # machine considers itself the final destination for. # # These domains are routed to the delivery agent specified with the # local_transport parameter setting. By default, that is the UNIX # compatible delivery agent that lookups all recipients in /etc/passwd # and /etc/aliases or their equivalent. # # The default is $myhostname + localhost.$mydomain. On a mail domain # gateway, you should also include $mydomain. # # Do not specify the names of virtual domains - those domains are # specified elsewhere (see VIRTUAL_README). # # Do not specify the names of domains that this machine is backup MX # host for. Specify those names via the relay_domains settings for # the SMTP server, or use permit_mx_backup if you are lazy (see # STANDARD_CONFIGURATION_README). # # The local machine is always the final destination for mail addressed # to user(a)[the.net.work.address] of an interface that the mail system # receives mail on (see the inet_interfaces parameter). # # Specify a list of host or domain names, /file/name or type:table # patterns, separated by commas and/or whitespace. A /file/name # pattern is replaced by its contents; a type:table is matched when # a name matches a lookup key (the right-hand side is ignored). # Continue long lines by starting the next line with whitespace. # # See also below, section "REJECTING MAIL FOR UNKNOWN LOCAL USERS". # #mydestination = $myhostname, localhost.$mydomain, localhost #mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain #mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain, # mail.$mydomain, www.$mydomain, ftp.$mydomain # REJECTING MAIL FOR UNKNOWN LOCAL USERS # # The local_recipient_maps parameter specifies optional lookup tables # with all names or addresses of users that are local with respect # to $mydestination, $inet_interfaces or $proxy_interfaces. # # If this parameter is defined, then the SMTP server will reject # mail for unknown local users. This parameter is defined by default. # # To turn off local recipient checking in the SMTP server, specify # local_recipient_maps = (i.e. empty). # # The default setting assumes that you use the default Postfix local # delivery agent for local delivery. You need to update the # local_recipient_maps setting if: # # - You define $mydestination domain recipients in files other than # /etc/passwd, /etc/aliases, or the $virtual_alias_maps files. # For example, you define $mydestination domain recipients in # the $virtual_mailbox_maps files. # # - You redefine the local delivery agent in master.cf. # # - You redefine the "local_transport" setting in main.cf. # # - You use the "luser_relay", "mailbox_transport", or "fallback_transport" # feature of the Postfix local delivery agent (see local(8)). # # Details are described in the LOCAL_RECIPIENT_README file. # # Beware: if the Postfix SMTP server runs chrooted, you probably have # to access the passwd file via the proxymap service, in order to # overcome chroot restrictions. The alternative, having a copy of # the system passwd file in the chroot jail is just not practical. # # The right-hand side of the lookup tables is conveniently ignored. # In the left-hand side, specify a bare username, an @domain.tld # wild-card, or specify a user(a)domain.tld address. # #local_recipient_maps = unix:passwd.byname $alias_maps #local_recipient_maps = proxy:unix:passwd.byname $alias_maps #local_recipient_maps = # The unknown_local_recipient_reject_code specifies the SMTP server # response code when a recipient domain matches $mydestination or # ${proxy,inet}_interfaces, while $local_recipient_maps is non-empty # and the recipient address or address local-part is not found. # # The default setting is 550 (reject mail) but it is safer to start # with 450 (try again later) until you are certain that your # local_recipient_maps settings are OK. # # TRUST AND RELAY CONTROL # The mynetworks parameter specifies the list of "trusted" SMTP # clients that have more privileges than "strangers". # # In particular, "trusted" SMTP clients are allowed to relay mail # through Postfix. See the smtpd_recipient_restrictions parameter # in postconf(5). # # You can specify the list of "trusted" network addresses by hand # or you can let Postfix do it for you (which is the default). # # By default (mynetworks_style = subnet), Postfix "trusts" SMTP # clients in the same IP subnetworks as the local machine. # On Linux, this does works correctly only with interfaces specified # with the "ifconfig" command. # # Specify "mynetworks_style = class" when Postfix should "trust" SMTP # clients in the same IP class A/B/C networks as the local machine. # Don't do this with a dialup site - it would cause Postfix to "trust" # your entire provider's network. Instead, specify an explicit # mynetworks list by hand, as described below. # # Specify "mynetworks_style = host" when Postfix should "trust" # only the local machine. # #mynetworks_style = class #mynetworks_style = subnet #mynetworks_style = host # Alternatively, you can specify the mynetworks list by hand, in # which case Postfix ignores the mynetworks_style setting. # # Specify an explicit list of network/netmask patterns, where the # mask specifies the number of bits in the network part of a host # address. # # You can also specify the absolute pathname of a pattern file instead # of listing the patterns here. Specify type:table for table-based lookups # (the value on the table right-hand side is not used). # #mynetworks = 168.100.189.0/28, 127.0.0.0/8 #mynetworks = $config_directory/mynetworks #mynetworks = hash:/etc/postfix/network_table # The relay_domains parameter restricts what destinations this system will # relay mail to. See the smtpd_recipient_restrictions description in # postconf(5) for detailed information. # # By default, Postfix relays mail # - from "trusted" clients (IP address matches $mynetworks) to any destination, # - from "untrusted" clients to destinations that match $relay_domains or # subdomains thereof, except addresses with sender-specified routing. # The default relay_domains value is $mydestination. # # In addition to the above, the Postfix SMTP server by default accepts mail # that Postfix is final destination for: # - destinations that match $inet_interfaces or $proxy_interfaces, # - destinations that match $mydestination # - destinations that match $virtual_alias_domains, # - destinations that match $virtual_mailbox_domains. # These destinations do not need to be listed in $relay_domains. # # Specify a list of hosts or domains, /file/name patterns or type:name # lookup tables, separated by commas and/or whitespace. Continue # long lines by starting the next line with whitespace. A file name # is replaced by its contents; a type:name table is matched when a # (parent) domain appears as lookup key. # # NOTE: Postfix will not automatically forward mail for domains that # list this system as their primary or backup MX host. See the # permit_mx_backup restriction description in postconf(5). # #relay_domains = $mydestination # INTERNET OR INTRANET # The relayhost parameter specifies the default host to send mail to # when no entry is matched in the optional transport(5) table. When # no relayhost is given, mail is routed directly to the destination. # # On an intranet, specify the organizational domain name. If your # internal DNS uses no MX records, specify the name of the intranet # gateway host instead. # # In the case of SMTP, specify a domain, host, host:port, [host]:port, # [address] or [address]:port; the form [host] turns off MX lookups. # # If you're connected via UUCP, see also the default_transport parameter. # #relayhost = $mydomain #relayhost = [gateway.my.domain] #relayhost = [mailserver.isp.tld] #relayhost = uucphost #relayhost = [an.ip.add.ress] # REJECTING UNKNOWN RELAY USERS # # The relay_recipient_maps parameter specifies optional lookup tables # with all addresses in the domains that match $relay_domains. # # If this parameter is defined, then the SMTP server will reject # mail for unknown relay users. This feature is off by default. # # The right-hand side of the lookup tables is conveniently ignored. # In the left-hand side, specify an @domain.tld wild-card, or specify # a user(a)domain.tld address. # #relay_recipient_maps = hash:/etc/postfix/relay_recipients # INPUT RATE CONTROL # # The in_flow_delay configuration parameter implements mail input # flow control. This feature is turned on by default, although it # still needs further development (it's disabled on SCO UNIX due # to an SCO bug). # # A Postfix process will pause for $in_flow_delay seconds before # accepting a new message, when the message arrival rate exceeds the # message delivery rate. With the default 100 SMTP server process # limit, this limits the mail inflow to 100 messages a second more # than the number of messages delivered per second. # # Specify 0 to disable the feature. Valid delays are 0..10. # #in_flow_delay = 1s # ADDRESS REWRITING # # The ADDRESS_REWRITING_README document gives information about # address masquerading or other forms of address rewriting including # username->Firstname.Lastname mapping. # ADDRESS REDIRECTION (VIRTUAL DOMAIN) # # The VIRTUAL_README document gives information about the many forms # of domain hosting that Postfix supports. # "USER HAS MOVED" BOUNCE MESSAGES # # See the discussion in the ADDRESS_REWRITING_README document. # TRANSPORT MAP # # See the discussion in the ADDRESS_REWRITING_README document. # ALIAS DATABASE # # The alias_maps parameter specifies the list of alias databases used # by the local delivery agent. The default list is system dependent. # # On systems with NIS, the default is to search the local alias # database, then the NIS alias database. See aliases(5) for syntax # details. # # If you change the alias database, run "postalias /etc/aliases" (or # wherever your system stores the mail alias file), or simply run # "newaliases" to build the necessary DBM or DB file. # # It will take a minute or so before changes become visible. Use # "postfix reload" to eliminate the delay. # #alias_maps = dbm:/etc/aliases #alias_maps = hash:/etc/aliases #alias_maps = hash:/etc/aliases, nis:mail.aliases #alias_maps = netinfo:/aliases # The alias_database parameter specifies the alias database(s) that # are built with "newaliases" or "sendmail -bi". This is a separate # configuration parameter, because alias_maps (see above) may specify # tables that are not necessarily all under control by Postfix. # #alias_database = dbm:/etc/aliases #alias_database = dbm:/etc/mail/aliases #alias_database = hash:/etc/aliases #alias_database = hash:/etc/aliases, hash:/opt/majordomo/aliases # ADDRESS EXTENSIONS (e.g., user+foo) # # The recipient_delimiter parameter specifies the separator between # user names and address extensions (user+foo). See canonical(5), # local(8), relocated(5) and virtual(5) for the effects this has on # aliases, canonical, virtual, relocated and .forward file lookups. # Basically, the software tries user+foo and .forward+foo before # trying user and .forward. # #recipient_delimiter = + # DELIVERY TO MAILBOX # # The home_mailbox parameter specifies the optional pathname of a # mailbox file relative to a user's home directory. The default # mailbox file is /var/spool/mail/user or /var/mail/user. Specify # "Maildir/" for qmail-style delivery (the / is required). # #home_mailbox = Mailbox #home_mailbox = Maildir/ # The mail_spool_directory parameter specifies the directory where # UNIX-style mailboxes are kept. The default setting depends on the # system type. # #mail_spool_directory = /var/mail #mail_spool_directory = /var/spool/mail # The mailbox_command parameter specifies the optional external # command to use instead of mailbox delivery. The command is run as # the recipient with proper HOME, SHELL and LOGNAME environment settings. # Exception: delivery for root is done as $default_user. # # Other environment variables of interest: USER (recipient username), # EXTENSION (address extension), DOMAIN (domain part of address), # and LOCAL (the address localpart). # # Unlike other Postfix configuration parameters, the mailbox_command # parameter is not subjected to $parameter substitutions. This is to # make it easier to specify shell syntax (see example below). # # Avoid shell meta characters because they will force Postfix to run # an expensive shell process. Procmail alone is expensive enough. # # IF YOU USE THIS TO DELIVER MAIL SYSTEM-WIDE, YOU MUST SET UP AN # ALIAS THAT FORWARDS MAIL FOR ROOT TO A REAL USER. # #mailbox_command = /some/where/procmail #mailbox_command = /some/where/procmail -a "$EXTENSION" # The mailbox_transport specifies the optional transport in master.cf # to use after processing aliases and .forward files. This parameter # has precedence over the mailbox_command, fallback_transport and # luser_relay parameters. # # Specify a string of the form transport:nexthop, where transport is # the name of a mail delivery transport defined in master.cf. The # :nexthop part is optional. For more details see the sample transport # configuration file. # # NOTE: if you use this feature for accounts not in the UNIX password # file, then you must update the "local_recipient_maps" setting in # the main.cf file, otherwise the SMTP server will reject mail for # non-UNIX accounts with "User unknown in local recipient table". # #mailbox_transport = lmtp:unix:/file/name #mailbox_transport = cyrus # The fallback_transport specifies the optional transport in master.cf # to use for recipients that are not found in the UNIX passwd database. # This parameter has precedence over the luser_relay parameter. # # Specify a string of the form transport:nexthop, where transport is # the name of a mail delivery transport defined in master.cf. The # :nexthop part is optional. For more details see the sample transport # configuration file. # # NOTE: if you use this feature for accounts not in the UNIX password # file, then you must update the "local_recipient_maps" setting in # the main.cf file, otherwise the SMTP server will reject mail for # non-UNIX accounts with "User unknown in local recipient table". # #fallback_transport = lmtp:unix:/file/name #fallback_transport = cyrus #fallback_transport = # The luser_relay parameter specifies an optional destination address # for unknown recipients. By default, mail for unknown@$mydestination, # unknown@[$inet_interfaces] or unknown@[$proxy_interfaces] is returned # as undeliverable. # # The following expansions are done on luser_relay: $user (recipient # username), $shell (recipient shell), $home (recipient home directory), # $recipient (full recipient address), $extension (recipient address # extension), $domain (recipient domain), $local (entire recipient # localpart), $recipient_delimiter. Specify ${name?value} or # ${name:value} to expand value only when $name does (does not) exist. # # luser_relay works only for the default Postfix local delivery agent. # # NOTE: if you use this feature for accounts not in the UNIX password # file, then you must specify "local_recipient_maps =" (i.e. empty) in # the main.cf file, otherwise the SMTP server will reject mail for # non-UNIX accounts with "User unknown in local recipient table". # #luser_relay = $user(a)other.host #luser_relay = $local(a)other.host #luser_relay = admin+$local unknown_local_recipient_reject_code=550 # JUNK MAIL CONTROLS # # The controls listed here are only a very small subset. The file # SMTPD_ACCESS_README provides an overview. # The header_checks parameter specifies an optional table with patterns # that each logical message header is matched against, including # headers that span multiple physical lines. # # By default, these patterns also apply to MIME headers and to the # headers of attached messages. With older Postfix versions, MIME and # attached message headers were treated as body text. # # For details, see "man header_checks". # #header_checks = regexp:/etc/postfix/header_checks # FAST ETRN SERVICE # # Postfix maintains per-destination logfiles with information about # deferred mail, so that mail can be flushed quickly with the SMTP # "ETRN domain.tld" command, or by executing "sendmail -qRdomain.tld". # See the ETRN_README document for a detailed description. # # The fast_flush_domains parameter controls what destinations are # eligible for this service. By default, they are all domains that # this server is willing to relay mail to. # #fast_flush_domains = $relay_domains # SHOW SOFTWARE VERSION OR NOT # # The smtpd_banner parameter specifies the text that follows the 220 # code in the SMTP server's greeting banner. Some people like to see # the mail version advertised. By default, Postfix shows no version. # # You MUST specify $myhostname at the start of the text. That is an # RFC requirement. Postfix itself does not care. # #smtpd_banner = $myhostname ESMTP $mail_name #smtpd_banner = $myhostname ESMTP $mail_name ($mail_version) # PARALLEL DELIVERY TO THE SAME DESTINATION # # How many parallel deliveries to the same user or domain? With local # delivery, it does not make sense to do massively parallel delivery # to the same user, because mailbox updates must happen sequentially, # and expensive pipelines in .forward files can cause disasters when # too many are run at the same time. With SMTP deliveries, 10 # simultaneous connections to the same domain could be sufficient to # raise eyebrows. # # Each message delivery transport has its XXX_destination_concurrency_limit # parameter. The default is $default_destination_concurrency_limit for # most delivery transports. For the local delivery agent the default is 2. #local_destination_concurrency_limit = 2 #default_destination_concurrency_limit = 20 # DEBUGGING CONTROL # # The debug_peer_level parameter specifies the increment in verbose # logging level when an SMTP client or server host name or address # matches a pattern in the debug_peer_list parameter. debug_peer_level=2 # The debug_peer_list parameter specifies an optional list of domain # or network patterns, /file/name patterns or type:name tables. When # an SMTP client or server host name or address matches a pattern, # increase the verbose logging level by the amount specified in the # debug_peer_level parameter. # #debug_peer_list = 127.0.0.1 #debug_peer_list = some.domain # The debugger_command specifies the external command that is executed # when a Postfix daemon program is run with the -D option. # # Use "command .. & sleep 5" so that the debugger can attach before # the process marches on. If you use an X-based debugger, be sure to # set up your XAUTHORITY environment variable before starting Postfix. debugger_command=PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd $daemon_directory/$process_name $process_id & sleep 5 # If you can't use X, use this to capture the call stack when a # daemon crashes. The result is in a file in the configuration # directory, and is named after the process name and the process ID. # # debugger_command = # PATH=/bin:/usr/bin:/usr/local/bin; export PATH; (echo cont; # echo where) | gdb $daemon_directory/$process_name $process_id 2>&1 # >$config_directory/$process_name.$process_id.log & sleep 5 # # Another possibility is to run gdb under a detached screen session. # To attach to the screen sesssion, su root and run "screen -r # <id_string>" where <id_string> uniquely matches one of the detached # sessions (from "screen -list"). # # debugger_command = # PATH=/bin:/usr/bin:/sbin:/usr/sbin; export PATH; screen # -dmS $process_name gdb $daemon_directory/$process_name # $process_id & sleep 1 # INSTALL-TIME CONFIGURATION INFORMATION # # The following parameters are used when installing a new Postfix version. # # sendmail_path: The full pathname of the Postfix sendmail command. # This is the Sendmail-compatible mail posting interface. # sendmail_path=/usr/sbin/sendmail # newaliases_path: The full pathname of the Postfix newaliases command. # This is the Sendmail-compatible command to build alias databases. newaliases_path=/usr/bin/newaliases # mailq_path: The full pathname of the Postfix mailq command. This # is the Sendmail-compatible mail queue listing command. # mailq_path=/usr/bin/mailq # setgid_group: The group for mail submission and queue management # commands. This must be a group name with a numerical group ID that # is not shared with other accounts, not even with the Postfix account. setgid_group=maildrop # html_directory: The location of the Postfix HTML documentation. html_directory=/usr/share/doc/packages/postfix-doc/html # manpage_directory: The location of the Postfix on-line manual pages. manpage_directory=/usr/share/man # sample_directory: The location of the Postfix sample configuration files. # This parameter is obsolete as of Postfix 2.1. sample_directory=/usr/share/doc/packages/postfix-doc/samples # readme_directory: The location of the Postfix README files. readme_directory=/usr/share/doc/packages/postfix-doc/README_FILES inet_protocols=all biff=no mail_spool_directory= canonical_maps=hash:/etc/postfix/canonical virtual_alias_maps=ldap:/etc/postfix/ldaplocal_recipient_maps.cf virtual_alias_domains=ldap:/etc/postfix/ldapvirtual_alias_maps.cf relocated_maps=hash:/etc/postfix/relocated transport_maps=ldap:/etc/postfix/ldaptransport_maps.cf sender_canonical_maps=hash:/etc/postfix/sender_canonical masquerade_exceptions=root masquerade_classes=envelope_sender, header_sender, header_recipient myhostname=Antiquitera.site delay_warning_time=1h message_strip_characters=\0 program_directory=/usr/lib/postfix inet_interfaces=all masquerade_domains=ldap:/etc/postfix/ldapmasquerade_domains.cf mydestination=$myhostname, localhost.$mydomain, $mydomain, ldap:/etc/postfix/ldapmydestination.cf defer_transports= mynetworks_style=subnet disable_dns_lookups=no relayhost= mailbox_command= mailbox_transport=lmtp:unix:/var/lib/imap/socket/lmtp strict_8bitmime=no disable_mime_output_conversion=no smtpd_sender_restrictions=ldap:/etc/postfix/ldapaccess.cf, reject_unknown_sender_domain smtpd_client_restrictions=ldap:/etc/postfix/ldapaccess.cf smtpd_helo_required=yes smtpd_helo_restrictions= strict_rfc821_envelopes=no smtpd_recipient_restrictions=permit_sasl_authenticated, permit_auth_destination, permit_mynetworks, reject_unauth_destination, reject smtp_sasl_auth_enable=no smtpd_sasl_auth_enable=yes smtpd_use_tls=yes smtp_use_tls=yes alias_maps=hash:/etc/aliases, ldap:/etc/postfix/ldapalias_maps_member.cf, ldap:/etc/postfix/ldapalias_maps.cf mailbox_size_limit=0 message_size_limit=10240000 smtp_enforce_tls=no smtp_tls_enforce_peername=yes smtpd_banner=$myhostname ESMTP $mail_name smtp_sasl_security_options=noanonymous local_recipient_maps=$alias_maps, ldap:/etc/postfix/ldaplocal_recipient_maps.cf mynetworks= smtpd_tls_auth_only=no smtpd_tls_cert_file=/etc/ssl/servercerts/servercert.pem smtpd_tls_key_file=/etc/ssl/servercerts/serverkey.pem smtpd_tls_CApath=/etc/ssl/certs home_mailbox= smtp_tls_per_site=ldap:/etc/postfix/ldapsmtp_tls_per_site.cf content_filter= -- Para dar de baja la suscripciÃ³n, mande un mensaje a: opensuse-es+unsubscribe(a)opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help(a)opensuse.org

2 2

[opensuse-es] Duda con las particiones
by SatOF 16 Jun '09

16 Jun '09

Hola, he instalado un suse en un servidor con un asistente que carga todos los drivers de la controladora de disco sin problema, pero deja las particiones de una manera que no habia visto nunca: Device Boot Start End Blocks Id System /dev/sda1 * 1 66 530113+ 83 Linux /dev/sda2 67 449 3076447+ 82 Linux swap / Solaris /dev/sda3 450 5549 40965750 83 Linux /dev/sda4 5550 30272 198587497+ f W95 Ext'd (LBA) /dev/sda5 5550 30272 198587466 83 Linux /dev/sda4 y /dev/sda5 empiezan y acaban en el mismo punto, la que es linux es primaria y la otra secundaria, segun veo, si hago df -h: Filesystem Size Used Avail Use% Mounted on /dev/sda3 39G 2.4G 35G 7% / udev 1013M 132K 1013M 1% /dev /dev/sda1 510M 24M 460M 5% /boot /dev/sda5 187G 189M 177G 1% /home la que es extendida no aparece, ni se puede montar: mount /dev/sda4 /mnt mount: /dev/sda4: can't read superblock Si borro /dev/sda4 tambien desaparece la dev/sda5. El problema es que no lo puedo instalar de otra manera mas que con el asistente, ¿ puede alguien explicarme este modo de particionar? Como siempre, gracias. -- Para dar de baja la suscripciÃ³n, mande un mensaje a: opensuse-es+unsubscribe(a)opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help(a)opensuse.org

5 25

[opensuse-es] Storage compartido
by Koxkorrita 16 Jun '09

16 Jun '09

Resulta que entre dos linux tengo que montar una zona compartida. Los usuarios me van a subir cantidades ingentes de ficheros a tratar. son dos maquinas , una los recibe y otra los trata. mi idea era montar = el Home de la maquina 1 (maquina que los recibe) de tal manera que ahi me = meten todos los ficheros (teras) en la maquina 2 esa zona de "storage compartido" la montar=EDa por = ejemplo en /tmp/tratamientos de tal manera que tengo acceso a esa zona para leer y luego escribir el resultado del tratamiento . es esto posible? Gracias -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe(a)opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help(a)opensuse.org

4 4

[opensuse-es] Linux y Nokia 5800
by Alejo 14 Jun '09

14 Jun '09

Hola a todos: Tengo un Nokia 5800 (regalo con una promocion) y la verdad me da mucha rabia no poder sincronizar con suse. Tras navegar y trastear por la red y por si a alguien le interesa. http://www8.garmin.com/support/collection.jsp?product=010-00579-00 Tengo que hacer pruebas porque no se que eso de funambol. Saludos Alejo -- Para dar de baja la suscripciÃ³n, mande un mensaje a: opensuse-es+unsubscribe(a)opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help(a)opensuse.org

5 5

[opensuse-es] impresora usb Epson sx105 multifuncion
by koxmoz kox 14 Jun '09

14 Jun '09

Que tal señores queria saber so alguien la hizo funcionar, porque he conseguido el driver, se ha instalado el driver, fue facil, la detecta, pero no me deja imprimir, ni me deja escanear, intente imprimir y dice: unable to start filter "pips wrapper - no such file or directory" y si intento usar xsane, y me pone: Fallo al abrir el dispositivo, "epkowa:usb:003:009" acceso al recurso fue prohibido. nose si hay alguna forma de probarlo, o de dar permisos, yast intente hacer una impresion de prueba con yast pero hizo nada·!·!· alguien tiene alguna idea?? -- Koxmoz Kox suselife.wordpress.com koxmox.wordpress.com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe(a)opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help(a)opensuse.org

2 4

[opensuse-es] Problema con el keymap
by Roberto Blandino 14 Jun '09

14 Jun '09

Tengo una maquina DELL Inspiron 1545, Core 2 DUO, 4GB RAM, VIDEO INTEL, bueno si bien recuerdan antes tenia una maquina Compaq N600c PIII de 512 MB RAM con tarjeta ATI, me a ido bien y pues decidi en comprarme la DELL, todo me ha ido bien, pues el wireless no lo detecta al instalar opensuse, puesto que hay que usar ndiswrapper para que reconozca la tarjeta Broadcom Corporation BCM4310 USB Controller, esto ya que el driver BCM43XXX solo es para pci. Bueno todo bien hasta que note algo, cuando recien instale mi maquina probe y configure mis multimedia keys o hotkeys, pues me las reconocio sin problemas y solo las configure en los accesos rapidos, mas sin embargo despues de realizar actualizaciones estas ya no me han funcionado de pronto, sin darme cuenta, solo hasta que quise usarlas, el brillo me funciona bien, incluso la tecla del wireless, la tecla para ejectar el cdrom tambien, lo que no me va son las tres teclas del sonido, el mute, el upsound y el lowersound. Ha un detalle que olvidaba uso opensuse 11.0 64bits, eso no es la causa ya que me funcionaban al instalarse. He trabajado con el setkeycodes anteriormente y pues eso sabiendo el mapa del teclado pero no he encontrado el mapa para esta laptop puesto que hotkeysetup es para otros modelos no me funciona ese mapa de configuracion, ademas la tecla que no me reconoce es la de cambio de pantalla puesto a que es la unica que me dice: atkbd.c: Unknown key pressed (translated set 2, code 0x8b on isa0060/serio0). atkbd.c: Use 'setkeycodes e00b <keycode>' to make it known. El resto no me arroja nada por lo que si estan mapeadas pero en kde4 no me funciona, otro detalle, cuando las configuro en TWM, si funcionan, puesto a que ejecuto kwin, luego systemsettings y luego pruebo las teclas y funciona. Esto me ha llevado a la conclusion que puede ser el kde4, pero aun no logro deducir donde puede estar fallando ya que al oprimir las teclas para configurar el accesos directo del kmix en systemsettings con el kde4, no me la reconoce. Espero me den alguna idea que puede ser. puesto a que no veo ningun error en el log cuando oprimo las teclas, es decir que si kde4 estuviese fallando deberia de arrojar algo no? Bueno estoy con esta incognita y espero me den alguna pista -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe(a)opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help(a)opensuse.org

2 1